Seung-Woo Kim [Wed, 17 May 2023 10:15:28 +0000 (19:15 +0900)]
soc: samsung: acpm: fix misleading indentation warning
Fix build warning with -Wmisleading-indentation.
Change-Id: I627745949a5b008515407067859a286b615d3712
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Seung-Woo Kim [Wed, 17 May 2023 10:10:59 +0000 (19:10 +0900)]
power: energy_monitor: Fix misleading indentation warning
Fix build warnings with -Wmisleading-indentation.
Change-Id: I9a0b8ed50338924e2dd8e390476c4df95022343c
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Seung-Woo Kim [Wed, 3 May 2023 06:59:07 +0000 (15:59 +0900)]
sched/core: fix build warning without CONFIG_CPUMASK_OFFSTACK
Without CONFIG_CPUMASK_OFFSTACK, checking the address of the
cpumask_var_t gives warning. To resolve the warning, use
cpumask_available() instead of checking the pointer directly.
Change-Id: I00b5a90015a304a4b1151afd1074acf9c542cb55
Ref: commit
e78c59fda86c ("cpumask: Add helper cpumask_available()")
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Nathan Chancellor [Thu, 5 Dec 2019 00:50:50 +0000 (16:50 -0800)]
kernel/profile.c: use cpumask_available to check for NULL cpumask
When building with clang + -Wtautological-pointer-compare, these
instances pop up:
kernel/profile.c:339:6: warning: comparison of array 'prof_cpu_mask' not equal to a null pointer is always true [-Wtautological-pointer-compare]
if (prof_cpu_mask != NULL)
^~~~~~~~~~~~~ ~~~~
kernel/profile.c:376:6: warning: comparison of array 'prof_cpu_mask' not equal to a null pointer is always true [-Wtautological-pointer-compare]
if (prof_cpu_mask != NULL)
^~~~~~~~~~~~~ ~~~~
kernel/profile.c:406:26: warning: comparison of array 'prof_cpu_mask' not equal to a null pointer is always true [-Wtautological-pointer-compare]
if (!user_mode(regs) && prof_cpu_mask != NULL &&
^~~~~~~~~~~~~ ~~~~
3 warnings generated.
This can be addressed with the cpumask_available helper, introduced in
commit
f7e30f01a9e2 ("cpumask: Add helper cpumask_available()") to fix
warnings like this while keeping the code the same.
Link: https://github.com/ClangBuiltLinux/linux/issues/747
Link: http://lkml.kernel.org/r/20191022191957.9554-1-natechancellor@gmail.com
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[sw0312.kim: backport upstream commit
ef70eff9dea6 to resolve gcc-12 build issue]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: Ifbe97caa3ee7b2db0f071ba036218db7fe5a58fd
Matthias Kaehlcke [Fri, 21 Apr 2017 23:41:10 +0000 (16:41 -0700)]
tracing: Use cpumask_available() to check if cpumask variable may be used
commit
4dbbe2d8e95c351157f292ece067f985c30c7b53 upstream.
This fixes the following clang warning:
kernel/trace/trace.c:3231:12: warning: address of array 'iter->started'
will always evaluate to 'true' [-Wpointer-bool-conversion]
if (iter->started)
Link: http://lkml.kernel.org/r/20170421234110.117075-1-mka@chromium.org
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[sw0312.kim: cherry-pick stable linux-4.9.y commit
8bd71286fde0 to resolve gcc-12 build issue]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: Iabd1372f13ff62ad37444f232e4cd2735eed6d7c
Matthias Kaehlcke [Wed, 12 Apr 2017 18:20:30 +0000 (11:20 -0700)]
genirq: Use cpumask_available() for check of cpumask variable
commit
d170fe7dd992b313d4851ae5ab77ee7a51ed8c72 upstream.
This fixes the following clang warning when CONFIG_CPUMASK_OFFSTACK=n:
kernel/irq/manage.c:839:28: error: address of array
'desc->irq_common_data.affinity' will always evaluate to 'true'
[-Werror,-Wpointer-bool-conversion]
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Cc: Grant Grundler <grundler@chromium.org>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Greg Hackmann <ghackmann@google.com>
Cc: Michael Davidson <md@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Link: http://lkml.kernel.org/r/20170412182030.83657-2-mka@chromium.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[sw0312.kim: cherry-pick stable linux-4.9.y commit
02e3a7d445c3 to resolve gcc-12 build issue]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I675cfbb085d994d86e4055ad7e002dcef92a4333
Will Deacon [Thu, 10 Aug 2017 12:19:09 +0000 (13:19 +0100)]
UPSTREAM: arm64: mm: Move ASID from TTBR0 to TTBR1
In preparation for mapping kernelspace and userspace with different
ASIDs, move the ASID to TTBR1 and update switch_mm to context-switch
TTBR0 via an invalid mapping (the zero page).
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Tested-by: Laura Abbott <labbott@redhat.com>
Tested-by: Shanker Donthineni <shankerd@codeaurora.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
(cherry picked from commit
7655abb953860485940d4de74fb45a8192149bb6)
[toddpoynor@google.com: add missing mrs inst from context]
Signed-off-by: Todd Poynor <toddpoynor@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
[sw0312.kim: cherry-pick android.googlesource.com/kernel/common commit to resolve gcc-12 build issue]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I9575ae2f0b3b5383c44f7ace0ac50588be739e45
Will Deacon [Thu, 13 Sep 2018 12:30:45 +0000 (13:30 +0100)]
arm64: Avoid redundant type conversions in xchg() and cmpxchg()
commit
5ef3fe4cecdf82fdd71ce78988403963d01444d4 upstream.
Our atomic instructions (either LSE atomics of LDXR/STXR sequences)
natively support byte, half-word, word and double-word memory accesses
so there is no need to mask the data register prior to being stored.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[sw0312.kim: cherry-pick stable linux-4.9.y commit
73dc3ba7d9e9 to resolve gcc-12 build issue]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: Ia94bfbb9c90a2bc0bf2890757e2017d9b566c690
Robin Murphy [Fri, 12 May 2017 12:48:41 +0000 (13:48 +0100)]
arm64: Remove redundant mov from LL/SC cmpxchg
commit
8df728e1ae614f592961e51f65d3e3212ede5a75 upstream.
The cmpxchg implementation introduced by commit
c342f78217e8 ("arm64:
cmpxchg: patch in lse instructions when supported by the CPU") performs
an apparently redundant register move of [old] to [oldval] in the
success case - it always uses the same register width as [oldval] was
originally loaded with, and is only executed when [old] and [oldval] are
known to be equal anyway.
The only effect it seemingly does have is to take up a surprising amount
of space in the kernel text, as removing it reveals:
text data bss dec hex filename
12426658 1348614 4499749
18275021 116dacd vmlinux.o.new
12429238 1348614 4499749
18277601 116e4e1 vmlinux.o.old
Reviewed-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[sw0312.kim: cherry-pick stable linux-4.9.y commit
e32210d1f0fc to resolve gcc-12 build issue]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I6a44598721e1f452750a8f799955b8f8837901dc
Will Deacon [Mon, 30 Apr 2018 12:56:32 +0000 (13:56 +0100)]
arm64: cmpwait: Clear event register before arming exclusive monitor
[ Upstream commit
1cfc63b5ae60fe7e01773f38132f98d8b13a99a0 ]
When waiting for a cacheline to change state in cmpwait, we may immediately
wake-up the first time around the outer loop if the event register was
already set (for example, because of the event stream).
Avoid these spurious wakeups by explicitly clearing the event register
before loading the cacheline and setting the exclusive monitor.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[sw0312.kim: cherry-pick stable linux-4.9.y commit
fba1048559d3 to resolve gcc-12 build issue]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I7d6d81bd20b1d90d796b79c55b32810b0423e64d
Will Deacon [Mon, 21 May 2018 16:44:57 +0000 (17:44 +0100)]
arm64: lse: Add early clobbers to some input/output asm operands
commit
32c3fa7cdf0c4a3eb8405fc3e13398de019e828b upstream.
For LSE atomics that read and write a register operand, we need to
ensure that these operands are annotated as "early clobber" if the
register is written before all of the input operands have been consumed.
Failure to do so can result in the compiler allocating the same register
to both operands, leading to splats such as:
Unable to handle kernel paging request at virtual address
11111122222221
[...]
x1 :
1111111122222222 x0 :
1111111122222221
Process swapper/0 (pid: 1, stack limit = 0x000000008209f908)
Call trace:
test_atomic64+0x1360/0x155c
where x0 has been allocated as both the value to be stored and also the
atomic_t pointer.
This patch adds the missing clobbers.
Cc: <stable@vger.kernel.org>
Cc: Dave Martin <dave.martin@arm.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Reported-by: Mark Salter <msalter@redhat.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[sw0312.kim: cherry-pick stable linux-4.9.y commit
b27fb13e93b0 to resolve gcc-12 build issue]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I345fd9776175073cbd562f959a814a9c245f199f
Kees Cook [Sat, 12 Feb 2022 17:14:49 +0000 (09:14 -0800)]
etherdevice: Adjust ether_addr* prototypes to silence -Wstringop-overead
commit
2618a0dae09ef37728dab89ff60418cbe25ae6bd upstream.
With GCC 12, -Wstringop-overread was warning about an implicit cast from
char[6] to char[8]. However, the extra 2 bytes are always thrown away,
alignment doesn't matter, and the risk of hitting the edge of unallocated
memory has been accepted, so this prototype can just be converted to a
regular char *. Silences:
net/core/dev.c: In function ‘bpf_prog_run_generic_xdp’: net/core/dev.c:4618:21: warning: ‘ether_addr_equal_64bits’ reading 8 bytes from a region of size 6 [-Wstringop-overread]
4618 | orig_host = ether_addr_equal_64bits(eth->h_dest, > skb->dev->dev_addr);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
net/core/dev.c:4618:21: note: referencing argument 1 of type ‘const u8[8]’ {aka ‘const unsigned char[8]’}
net/core/dev.c:4618:21: note: referencing argument 2 of type ‘const u8[8]’ {aka ‘const unsigned char[8]’}
In file included from net/core/dev.c:91: include/linux/etherdevice.h:375:20: note: in a call to function ‘ether_addr_equal_64bits’
375 | static inline bool ether_addr_equal_64bits(const u8 addr1[6+2],
| ^~~~~~~~~~~~~~~~~~~~~~~
Reported-by: Marc Kleine-Budde <mkl@pengutronix.de>
Tested-by: Marc Kleine-Budde <mkl@pengutronix.de>
Link: https://lore.kernel.org/netdev/20220212090811.uuzk6d76agw2vv73@pengutronix.de
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Cc: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[sw0312.kim: cherry-pick stable linux-4.9.y commit
096879ef0c4c to resolve gcc-12 build issue]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: If57b1d1c9b0027abba79c34b384de87ef9c45db2
Xiongwei Song [Fri, 14 Jan 2022 22:07:24 +0000 (14:07 -0800)]
mm: page_alloc: fix building error on -Werror=array-compare
commit
ca831f29f8f25c97182e726429b38c0802200c8f upstream.
Arthur Marsh reported we would hit the error below when building kernel
with gcc-12:
CC mm/page_alloc.o
mm/page_alloc.c: In function `mem_init_print_info':
mm/page_alloc.c:8173:27: error: comparison between two arrays [-Werror=array-compare]
8173 | if (start <= pos && pos < end && size > adj) \
|
In C++20, the comparision between arrays should be warned.
Link: https://lkml.kernel.org/r/20211125130928.32465-1-sxwjean@me.com
Signed-off-by: Xiongwei Song <sxwjean@gmail.com>
Reported-by: Arthur Marsh <arthur.marsh@internode.on.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[sw0312.kim: cherry-pick stable linux-4.9.y commit
27057333467c to resolve gcc-12 build issue]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: Ifd2e97713a205497b95d26ee20a248b63dd0104b
Nathan Chancellor [Tue, 7 Apr 2020 03:09:27 +0000 (20:09 -0700)]
kernel/extable.c: use address-of operator on section symbols
Clang warns:
../kernel/extable.c:37:52: warning: array comparison always evaluates to
a constant [-Wtautological-compare]
if (main_extable_sort_needed && __stop___ex_table > __start___ex_table) {
^
1 warning generated.
These are not true arrays, they are linker defined symbols, which are just
addresses. Using the address of operator silences the warning and does
not change the resulting assembly with either clang/ld.lld or gcc/ld
(tested with diff + objdump -Dr).
Suggested-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
Link: https://github.com/ClangBuiltLinux/linux/issues/892
Link: http://lkml.kernel.org/r/20200219202036.45702-1-natechancellor@gmail.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[sw0312.kim: cherry-pick upstream commit
63174f61dfae to resolve gcc-12 build issue]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: Iead005392ebb5b2b334a7eae324883cc5f75c2cc
Sergei Trofimovich [Tue, 17 Mar 2020 00:07:18 +0000 (00:07 +0000)]
Makefile: disallow data races on gcc-10 as well
commit
b1112139a103b4b1101d0d2d72931f2d33d8c978 upstream.
gcc-10 will rename --param=allow-store-data-races=0
to -fno-allow-store-data-races.
The flag change happened at https://gcc.gnu.org/PR92046.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Acked-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Cc: Thomas Backlund <tmb@mageia.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[sw0312.kim: cherry-pick stable linux-4.9.y commit
3bead443ef3d to resolve gcc-12 build issue]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: Ie00c012440d4e3db2ac206be4c6086ef7795ffd5
Linus Torvalds [Sat, 9 May 2020 22:45:21 +0000 (15:45 -0700)]
gcc-10: disable 'restrict' warning for now
commit
adc71920969870dfa54e8f40dac8616284832d02 upstream.
gcc-10 now warns about passing aliasing pointers to functions that take
restricted pointers.
That's actually a great warning, and if we ever start using 'restrict'
in the kernel, it might be quite useful. But right now we don't, and it
turns out that the only thing this warns about is an idiom where we have
declared a few functions to be "printf-like" (which seems to make gcc
pick up the restricted pointer thing), and then we print to the same
buffer that we also use as an input.
And people do that as an odd concatenation pattern, with code like this:
#define sysfs_show_gen_prop(buffer, fmt, ...) \
snprintf(buffer, PAGE_SIZE, "%s"fmt, buffer, __VA_ARGS__)
where we have 'buffer' as both the destination of the final result, and
as the initial argument.
Yes, it's a bit questionable. And outside of the kernel, people do have
standard declarations like
int snprintf( char *restrict buffer, size_t bufsz,
const char *restrict format, ... );
where that output buffer is marked as a restrict pointer that cannot
alias with any other arguments.
But in the context of the kernel, that 'use snprintf() to concatenate to
the end result' does work, and the pattern shows up in multiple places.
And we have not marked our own version of snprintf() as taking restrict
pointers, so the warning is incorrect for now, and gcc picks it up on
its own.
If we do start using 'restrict' in the kernel (and it might be a good
idea if people find places where it matters), we'll need to figure out
how to avoid this issue for snprintf and friends. But in the meantime,
this warning is not useful.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[sw0312.kim: cherry-pick stable linux-4.9.y commit
9799d957182c to resolve gcc-12 build issue]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: Ic5e4a77aa06c371c2492ad1dd4e3abc274636172
Linus Torvalds [Sat, 9 May 2020 22:40:52 +0000 (15:40 -0700)]
gcc-10: disable 'stringop-overflow' warning for now
commit
5a76021c2eff7fcf2f0918a08fd8a37ce7922921 upstream.
This is the final array bounds warning removal for gcc-10 for now.
Again, the warning is good, and we should re-enable all these warnings
when we have converted all the legacy array declaration cases to
flexible arrays. But in the meantime, it's just noise.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[sw0312.kim: cherry-pick stable linux-4.9.y commit
01d51bb31251 to resolve gcc-12 build issue]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: Ib77eddcecffb54441f73d4324ad6abe7c7e2c4f5
Linus Torvalds [Sat, 9 May 2020 21:52:44 +0000 (14:52 -0700)]
gcc-10: disable 'array-bounds' warning for now
commit
44720996e2d79e47d508b0abe99b931a726a3197 upstream.
This is another fine warning, related to the 'zero-length-bounds' one,
but hitting the same historical code in the kernel.
Because C didn't historically support flexible array members, we have
code that instead uses a one-sized array, the same way we have cases of
zero-sized arrays.
The one-sized arrays come from either not wanting to use the gcc
zero-sized array extension, or from a slight convenience-feature, where
particularly for strings, the size of the structure now includes the
allocation for the final NUL character.
So with a "char name[1];" at the end of a structure, you can do things
like
v = my_malloc(sizeof(struct vendor) + strlen(name));
and avoid the "+1" for the terminator.
Yes, the modern way to do that is with a flexible array, and using
'offsetof()' instead of 'sizeof()', and adding the "+1" by hand. That
also technically gets the size "more correct" in that it avoids any
alignment (and thus padding) issues, but this is another long-term
cleanup thing that will not happen for 5.7.
So disable the warning for now, even though it's potentially quite
useful. Having a slew of warnings that then hide more urgent new issues
is not an improvement.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[sw0312.kim: cherry-pick stable linux-4.9.y commit
55e8e4b87b7b to resolve gcc-12 build issue]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I6ac0abb9ded5e96d706b37389691da637c1e28bf
Linus Torvalds [Sat, 9 May 2020 21:30:29 +0000 (14:30 -0700)]
gcc-10: disable 'zero-length-bounds' warning for now
commit
5c45de21a2223fe46cf9488c99a7fbcf01527670 upstream.
This is a fine warning, but we still have a number of zero-length arrays
in the kernel that come from the traditional gcc extension. Yes, they
are getting converted to flexible arrays, but in the meantime the gcc-10
warning about zero-length bounds is very verbose, and is hiding other
issues.
I missed one actual build failure because it was hidden among hundreds
of lines of warning. Thankfully I caught it on the second go before
pushing things out, but it convinced me that I really need to disable
the new warnings for now.
We'll hopefully be all done with our conversion to flexible arrays in
the not too distant future, and we can then re-enable this warning.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[sw0312.kim: cherry-pick stable linux-4.9.y commit
207ad349e232 to resolve gcc-12 build issue]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I0f784a9f1a8607340c50391ca06461cb1f4fcb23
Linus Torvalds [Mon, 4 May 2020 16:16:37 +0000 (09:16 -0700)]
gcc-10 warnings: fix low-hanging fruit
commit
9d82973e032e246ff5663c9805fbb5407ae932e3 upstream.
Due to a bug-report that was compiler-dependent, I updated one of my
machines to gcc-10. That shows a lot of new warnings. Happily they
seem to be mostly the valid kind, but it's going to cause a round of
churn for getting rid of them..
This is the really low-hanging fruit of removing a couple of zero-sized
arrays in some core code. We have had a round of these patches before,
and we'll have many more coming, and there is nothing special about
these except that they were particularly trivial, and triggered more
warnings than most.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[sw0312.kim: cherry-pick stable linux-4.9.y commit
5ba9126d709e to resolve gcc-12 build issue]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: Id1a8ba9d675bd125dc851b5868e43b2770ad27a0
Dirk Mueller [Tue, 14 Jan 2020 17:53:41 +0000 (18:53 +0100)]
scripts/dtc: Remove redundant YYLOC global declaration
commit
e33a814e772cdc36436c8c188d8c42d019fda639 upstream.
gcc 10 will default to -fno-common, which causes this error at link
time:
(.text+0x0): multiple definition of `yylloc'; dtc-lexer.lex.o (symbol from plugin):(.text+0x0): first defined here
This is because both dtc-lexer as well as dtc-parser define the same
global symbol yyloc. Before with -fcommon those were merged into one
defintion. The proper solution would be to to mark this as "extern",
however that leads to:
dtc-lexer.l:26:16: error: redundant redeclaration of 'yylloc' [-Werror=redundant-decls]
26 | extern YYLTYPE yylloc;
| ^~~~~~
In file included from dtc-lexer.l:24:
dtc-parser.tab.h:127:16: note: previous declaration of 'yylloc' was here
127 | extern YYLTYPE yylloc;
| ^~~~~~
cc1: all warnings being treated as errors
which means the declaration is completely redundant and can just be
dropped.
Signed-off-by: Dirk Mueller <dmueller@suse.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
[robh: cherry-pick from upstream]
Cc: stable@vger.kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>
[nc: Also apply to dtc-lexer.lex.c_shipped due to a lack of
e039139be8c2, where dtc-lexer.l started being used]
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[sw0312.kim: cherry-pick stable linux-4.9.y commit
8e8ab8554aa4 to resolve gcc-12 build issue]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I6b5238c0403794fc8ab07f7b1fac2119c93246fa
Seung-Woo Kim [Mon, 13 Dec 2021 04:48:27 +0000 (13:48 +0900)]
scripts: remove not use jar flie
Change-Id: Idb814c2d0170561328541b1478b9a1bf691cb1a7
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
INSUN PYO [Wed, 30 Jun 2021 02:24:33 +0000 (11:24 +0900)]
ARM64: defconfig: disable ANDROID_LOGGER config
Disable android logger.
The android logger has been moved to the kernel module of the linux-tizen-modules package.
Change-Id: Ibe761a22bd701b98db50937b369770da443a9041
Signed-off-by: INSUN PYO <insun.pyo@samsung.com>
Jaechul Lee [Tue, 20 Apr 2021 01:49:41 +0000 (10:49 +0900)]
arm64: config: tw3: enable CONFIG_SND_ALOOP
Enable CONFIG_SND_ALOOP for supporting Acoustic Echo Cancellation
Change-Id: Ib64a9209c9eaf746f6dd9b198f3330779ba08293
Signed-off-by: Jaechul Lee <jcsing.lee@samsung.com>
Jaechul Lee [Tue, 20 Apr 2021 01:41:09 +0000 (10:41 +0900)]
ALSA: aloop: Add 'PCM Master Active' control
Acoustic Echo Cancellation that is a tizen feature needs to know the
master active status to fall into a sleep when it doesn't need to
process any pcm data. 'PCM Master Active' control was added and
separated with 'PCM Slave Active' control. It will be notified to the
userspace when a user started to capture from aloop devices.
Change-Id: I4382c51dc30801b97d6a6d43e1ab36e0fa797393
Signed-off-by: Jaechul Lee <jcsing.lee@samsung.com>
Seung-Woo Kim [Tue, 20 Apr 2021 04:01:48 +0000 (13:01 +0900)]
drm: vblank: Revert back to wait requested vblank sequence
For DRM_IOCTL_WAIT_VBLANK with event flag, waiting requested
sequence routine was removed, so it always sends vblank
event after exact one vblank. Revert back to wait requested
vblank sequence.
Change-Id: If335cafde04fe699ed3d81f0d3f994e91244a5e4
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Jaehoon Chung [Wed, 17 Feb 2021 01:08:55 +0000 (10:08 +0900)]
ARM64: defconfig: disable SECURITY_SMACK_NETFILTER config
Disable SECURITY_SMACK_NETFILTER configuration.
Change-Id: I8b7260e54ad14770c9f64d05c75e84b9dc8fea34
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Jaehoon Chung [Tue, 25 Aug 2020 03:49:06 +0000 (12:49 +0900)]
ARM64: tizen_tw3_defconfig: enable a config prefech_128 for dm-verity
Enable CONFIG_DM_VEIRTY_HASH_PREFETCH_MIN_SIZE_128.
Change-Id: I2b8f8c8aa91f9e50429c7f5d76f9a2973973e6df
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Jaehoon Chung [Tue, 25 Aug 2020 03:48:58 +0000 (12:48 +0900)]
md: dm-verity-target: change prefetch size to 128 if config is enabled
If config is enabled, chagne prefetch size from 256 to 128.
It can be reduced the booting time about 10ms after enabling verity.
- With ignore_zero_blocks, it can be reduced about 100~120ms.
- it's dependent with storage, so it needs to check which value is best.
Change-Id: Id3ae01c143964fb3a41e66b407d20da410fa0441
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Maciej Słodczyk [Mon, 13 Jul 2020 12:59:57 +0000 (14:59 +0200)]
config: tw3: enable cpuset controller for cgroup
Make cpuset interface available for resourced daemon
to control tizen apps' cpu distribution and scheduling.
Change-Id: I459334c5322c9fc661e25c87ba54ffb9f1748a0c
Signed-off-by: Maciej Słodczyk <m.slodczyk2@partner.samsung.com>
Dongwoo Lee [Fri, 3 Jul 2020 02:05:59 +0000 (11:05 +0900)]
lib: zstd: huf_decompress: Cleanup code
This fixes to explicitly initialize variable before use and removes
redundant assignment.
Change-Id: Id424707b886bf5dfb5473e2535d29adc46c9d92f
Suggested-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
Dongwoo Lee [Thu, 4 Jun 2020 04:54:44 +0000 (13:54 +0900)]
lib: zstd: Improve decode performance
To speed up decode performance, optimizations are brought from zstd
github repository and ported as kernel-style.
Since the low-level algorithm is preferred in linux due to
compression/decompression performance (default level 3), the
optimization for low-level is chosed as follows:
[1] lib: zstd: Speed up single segment zstd_fast by 5%
(https://github.com/facebook/zstd/pull/1562/commits/
95624b77e477752b3c380c22be7bcf67f06c9934)
[2] perf improvements for zstd decode
(https://github.com/facebook/zstd/pull/1668/commits/
29d1e81bbdfc21085529623e7bc5abcb3e1627ae)
[3] updated double_fast complementary insertion
(https://github.com/facebook/zstd/pull/1681/commits/
d1327738c277643f09c972a407083ad73c8ecf7b)
[4] Improvements in zstd decode performance
(https://github.com/facebook/zstd/pull/1756/commits/
b83059958246dfcb5b91af9c187fad8c706869a0)
[5] Optimize decompression and fix wildcopy overread
(https://github.com/facebook/zstd/pull/1804/commits/
efd37a64eaff5a0a26ae2566fdb45dc4a0c91673)
[6] Improve ZSTD_highbit32's codegen
(https://github.com/facebook/zstd/commit/
a07da7b0db682c170a330a8c21585be3d68275fa)
[7] Optimize decompression speed for gcc and clang (#1892)
(https://github.com/facebook/zstd/commit/
718f00ff6fe42db7e6ba09a7f7992b3e85283f77)
[8] Fix performance regression on aarch64 with clang
(https://github.com/facebook/zstd/pull/1973/commits/
cb2abc3dbe010113d9e00ca3b612bf61983145a2)
Change-Id: I4f7bdba934383d2a5370e8da1ebf4314e0867d3e
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
Dongwoo Lee [Thu, 4 Jun 2020 04:54:35 +0000 (13:54 +0900)]
block: zram: Add support for dynamic compressor switch
Orginally, the compression algorithm cannot be changed until
resetting it if zram is once initialized by setting disksize. Since
this, however, zram can have multiple compressor and switch them
dynamically.
With this, zram uses the algorithm which is fast but has low
compression ratio at first, and can change to the one that is slightly
slower but having higher ratio when the target get bothered by low
memory.
Change-Id: Icf9ac074b340122532a10d4e28fd0c182dbcc8a9
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
Sergey Senozhatsky [Thu, 16 Nov 2017 01:33:49 +0000 (17:33 -0800)]
zram: add zstd to the supported algorithms list
Add ZSTD to the list of supported compression algorithms.
ZRAM fio perf test:
LZO DEFLATE ZSTD
WRITE: (2180MB/s) (77.2MB/s) (1429MB/s)
WRITE: (1617MB/s) (77.7MB/s) (1202MB/s)
READ: (426MB/s) (595MB/s) (1181MB/s)
READ: (422MB/s) (572MB/s) (1020MB/s)
READ: (318MB/s) (67.8MB/s) (563MB/s)
WRITE: (318MB/s) (67.9MB/s) (564MB/s)
READ: (336MB/s) (68.3MB/s) (583MB/s)
WRITE: (335MB/s) (68.2MB/s) (582MB/s)
WRITE: (3441MB/s) (152MB/s) (2141MB/s)
WRITE: (2507MB/s) (147MB/s) (1888MB/s)
READ: (801MB/s) (1146MB/s) (1890MB/s)
READ: (767MB/s) (1096MB/s) (2073MB/s)
READ: (621MB/s) (126MB/s) (1009MB/s)
WRITE: (621MB/s) (126MB/s) (1009MB/s)
READ: (656MB/s) (125MB/s) (1075MB/s)
WRITE: (657MB/s) (126MB/s) (1077MB/s)
WRITE: (4772MB/s) (225MB/s) (3394MB/s)
WRITE: (3905MB/s) (211MB/s) (2939MB/s)
READ: (1216MB/s) (1608MB/s) (3218MB/s)
READ: (1159MB/s) (1431MB/s) (2981MB/s)
READ: (906MB/s) (156MB/s) (1457MB/s)
WRITE: (907MB/s) (156MB/s) (1458MB/s)
READ: (953MB/s) (158MB/s) (1595MB/s)
WRITE: (952MB/s) (157MB/s) (1593MB/s)
WRITE: (6036MB/s) (265MB/s) (4469MB/s)
WRITE: (5059MB/s) (263MB/s) (3951MB/s)
READ: (1618MB/s) (2066MB/s) (4276MB/s)
READ: (1573MB/s) (1942MB/s) (3830MB/s)
READ: (1202MB/s) (227MB/s) (1971MB/s)
WRITE: (1200MB/s) (227MB/s) (1968MB/s)
READ: (1265MB/s) (226MB/s) (2116MB/s)
WRITE: (1264MB/s) (226MB/s) (2114MB/s)
WRITE: (5339MB/s) (233MB/s) (3781MB/s)
WRITE: (4298MB/s) (234MB/s) (3276MB/s)
READ: (1626MB/s) (2048MB/s) (4081MB/s)
READ: (1567MB/s) (1929MB/s) (3758MB/s)
READ: (1174MB/s) (205MB/s) (1747MB/s)
WRITE: (1173MB/s) (204MB/s) (1746MB/s)
READ: (1214MB/s) (208MB/s) (1890MB/s)
WRITE: (1215MB/s) (208MB/s) (1892MB/s)
WRITE: (5666MB/s) (270MB/s) (4338MB/s)
WRITE: (4828MB/s) (267MB/s) (3772MB/s)
READ: (1803MB/s) (2058MB/s) (4946MB/s)
READ: (1805MB/s) (2156MB/s) (4711MB/s)
READ: (1334MB/s) (235MB/s) (2135MB/s)
WRITE: (1335MB/s) (235MB/s) (2137MB/s)
READ: (1364MB/s) (236MB/s) (2268MB/s)
WRITE: (1365MB/s) (237MB/s) (2270MB/s)
WRITE: (5474MB/s) (270MB/s) (4300MB/s)
WRITE: (4666MB/s) (266MB/s) (3817MB/s)
READ: (2022MB/s) (2319MB/s) (5472MB/s)
READ: (1924MB/s) (2260MB/s) (5031MB/s)
READ: (1369MB/s) (242MB/s) (2153MB/s)
WRITE: (1370MB/s) (242MB/s) (2155MB/s)
READ: (1499MB/s) (246MB/s) (2310MB/s)
WRITE: (1497MB/s) (246MB/s) (2307MB/s)
WRITE: (5558MB/s) (273MB/s) (4439MB/s)
WRITE: (4763MB/s) (271MB/s) (3918MB/s)
READ: (2201MB/s) (2599MB/s) (6062MB/s)
READ: (2105MB/s) (2463MB/s) (5413MB/s)
READ: (1490MB/s) (252MB/s) (2238MB/s)
WRITE: (1488MB/s) (252MB/s) (2236MB/s)
READ: (1566MB/s) (254MB/s) (2434MB/s)
WRITE: (1568MB/s) (254MB/s) (2437MB/s)
WRITE: (5120MB/s) (264MB/s) (4035MB/s)
WRITE: (4531MB/s) (267MB/s) (3740MB/s)
READ: (1940MB/s) (2258MB/s) (4986MB/s)
READ: (2024MB/s) (2387MB/s) (4871MB/s)
READ: (1343MB/s) (246MB/s) (2038MB/s)
WRITE: (1342MB/s) (246MB/s) (2037MB/s)
READ: (1553MB/s) (238MB/s) (2243MB/s)
WRITE: (1552MB/s) (238MB/s) (2242MB/s)
WRITE: (5345MB/s) (271MB/s) (3988MB/s)
WRITE: (4750MB/s) (254MB/s) (3668MB/s)
READ: (1876MB/s) (2363MB/s) (5150MB/s)
READ: (1990MB/s) (2256MB/s) (5080MB/s)
READ: (1355MB/s) (250MB/s) (2019MB/s)
WRITE: (1356MB/s) (251MB/s) (2020MB/s)
READ: (1490MB/s) (252MB/s) (2202MB/s)
WRITE: (1488MB/s) (252MB/s) (2199MB/s)
jobs1 perfstat
instructions 52,065,555,710 ( 0.79) 855,731,114,587 ( 2.64) 54,280,709,944 ( 1.40)
branches 14,020,427,116 ( 725.847) 101,733,449,582 (1074.521) 11,170,591,067 ( 992.869)
branch-misses 22,626,174 ( 0.16%) 274,197,885 ( 0.27%) 25,915,805 ( 0.23%)
jobs2 perfstat
instructions 103,633,110,402 ( 0.75) 1,710,822,100,914 ( 2.59) 107,879,874,104 ( 1.28)
branches 27,931,237,282 ( 679.203) 203,298,267,479 (1037.326) 22,185,350,842 ( 884.427)
branch-misses 46,103,811 ( 0.17%) 533,747,204 ( 0.26%) 49,682,483 ( 0.22%)
jobs3 perfstat
instructions 154,857,283,657 ( 0.76) 2,565,748,974,197 ( 2.57) 161,515,435,813 ( 1.31)
branches 41,759,490,355 ( 670.529) 304,905,605,277 ( 978.765) 33,215,805,907 ( 888.003)
branch-misses 74,263,293 ( 0.18%) 759,746,240 ( 0.25%) 76,841,196 ( 0.23%)
jobs4 perfstat
instructions 206,215,849,076 ( 0.75) 3,420,169,460,897 ( 2.60) 215,003,061,664 ( 1.31)
branches 55,632,141,739 ( 666.501) 406,394,977,433 ( 927.241) 44,214,322,251 ( 883.532)
branch-misses 102,287,788 ( 0.18%) 1,098,617,314 ( 0.27%) 103,891,040 ( 0.23%)
jobs5 perfstat
instructions 258,711,315,588 ( 0.67) 4,275,657,533,244 ( 2.23) 269,332,235,685 ( 1.08)
branches 69,802,821,166 ( 588.823) 507,996,211,252 ( 797.036) 55,450,846,129 ( 735.095)
branch-misses 129,217,214 ( 0.19%) 1,243,284,991 ( 0.24%) 173,512,278 ( 0.31%)
jobs6 perfstat
instructions 312,796,166,008 ( 0.61) 5,133,896,344,660 ( 2.02) 323,658,769,588 ( 1.04)
branches 84,372,488,583 ( 520.541) 610,310,494,402 ( 697.642) 66,683,292,992 ( 693.939)
branch-misses 159,438,978 ( 0.19%) 1,396,368,563 ( 0.23%) 174,406,934 ( 0.26%)
jobs7 perfstat
instructions 363,211,372,930 ( 0.56) 5,988,205,600,879 ( 1.75) 377,824,674,156 ( 0.93)
branches 98,057,013,765 ( 463.117) 711,841,255,974 ( 598.762) 77,879,009,954 ( 600.443)
branch-misses 199,513,153 ( 0.20%) 1,507,651,077 ( 0.21%) 248,203,369 ( 0.32%)
jobs8 perfstat
instructions 413,960,354,615 ( 0.52) 6,842,918,558,378 ( 1.45) 431,938,486,581 ( 0.83)
branches 111,812,574,884 ( 414.224) 813,299,084,518 ( 491.173) 89,062,699,827 ( 517.795)
branch-misses 233,584,845 ( 0.21%) 1,531,593,921 ( 0.19%) 286,818,489 ( 0.32%)
jobs9 perfstat
instructions 465,976,220,300 ( 0.53) 7,698,467,237,372 ( 1.47) 486,352,600,321 ( 0.84)
branches 125,931,456,162 ( 424.063) 915,207,005,715 ( 498.192) 100,370,404,090 ( 517.439)
branch-misses 256,992,445 ( 0.20%) 1,782,809,816 ( 0.19%) 345,239,380 ( 0.34%)
jobs10 perfstat
instructions 517,406,372,715 ( 0.53) 8,553,527,312,900 ( 1.48) 540,732,653,094 ( 0.84)
branches 139,839,780,676 ( 427.732) 1,016,737,699,389 ( 503.172) 111,696,557,638 ( 516.750)
branch-misses 259,595,561 ( 0.19%) 1,952,570,279 ( 0.19%) 357,818,661 ( 0.32%)
seconds elapsed 20.
630411534 96.
084546565 12.
743373571
seconds elapsed 22.
292627625 100.
984155001 14.
407413560
seconds elapsed 22.
396016966 110.
344880848 14.
032201392
seconds elapsed 22.
517330949 113.
351459170 14.
243074935
seconds elapsed 28.
548305104 156.
515193765 19.
159286861
seconds elapsed 30.
453538116 164.
559937678 19.
362492717
seconds elapsed 33.
467108086 188.
486827481 21.
492612173
seconds elapsed 35.
617727591 209.
602677783 23.
256422492
seconds elapsed 42.
584239509 243.
959902566 28.
458540338
seconds elapsed 47.
683632526 269.
635248851 31.
542404137
Over all, ZSTD has slower WRITE, but much faster READ (perhaps
a static compression buffer used during the test helped ZSTD a
lot), which results in faster test results.
Memory consumption (zram mm_stat file):
zram LZO mm_stat
mm_stat (jobs1):
2147483648 23068672 33558528 0
33558528 0 0
mm_stat (jobs2):
2147483648 23068672 33558528 0
33558528 0 0
mm_stat (jobs3):
2147483648 23068672 33558528 0
33562624 0 0
mm_stat (jobs4):
2147483648 23068672 33558528 0
33558528 0 0
mm_stat (jobs5):
2147483648 23068672 33558528 0
33558528 0 0
mm_stat (jobs6):
2147483648 23068672 33558528 0
33562624 0 0
mm_stat (jobs7):
2147483648 23068672 33558528 0
33566720 0 0
mm_stat (jobs8):
2147483648 23068672 33558528 0
33558528 0 0
mm_stat (jobs9):
2147483648 23068672 33558528 0
33558528 0 0
mm_stat (jobs10):
2147483648 23068672 33558528 0
33562624 0 0
zram DEFLATE mm_stat
mm_stat (jobs1):
2147483648 16252928 25178112 0
25178112 0 0
mm_stat (jobs2):
2147483648 16252928 25178112 0
25178112 0 0
mm_stat (jobs3):
2147483648 16252928 25178112 0
25178112 0 0
mm_stat (jobs4):
2147483648 16252928 25178112 0
25178112 0 0
mm_stat (jobs5):
2147483648 16252928 25178112 0
25178112 0 0
mm_stat (jobs6):
2147483648 16252928 25178112 0
25178112 0 0
mm_stat (jobs7):
2147483648 16252928 25178112 0
25190400 0 0
mm_stat (jobs8):
2147483648 16252928 25178112 0
25190400 0 0
mm_stat (jobs9):
2147483648 16252928 25178112 0
25178112 0 0
mm_stat (jobs10):
2147483648 16252928 25178112 0
25178112 0 0
zram ZSTD mm_stat
mm_stat (jobs1):
2147483648 11010048 16781312 0
16781312 0 0
mm_stat (jobs2):
2147483648 11010048 16781312 0
16781312 0 0
mm_stat (jobs3):
2147483648 11010048 16781312 0
16785408 0 0
mm_stat (jobs4):
2147483648 11010048 16781312 0
16781312 0 0
mm_stat (jobs5):
2147483648 11010048 16781312 0
16781312 0 0
mm_stat (jobs6):
2147483648 11010048 16781312 0
16781312 0 0
mm_stat (jobs7):
2147483648 11010048 16781312 0
16781312 0 0
mm_stat (jobs8):
2147483648 11010048 16781312 0
16781312 0 0
mm_stat (jobs9):
2147483648 11010048 16781312 0
16785408 0 0
mm_stat (jobs10):
2147483648 11010048 16781312 0
16781312 0 0
==================================================================================
Official benchmarks [1]:
Compressor name Ratio Compression Decompress.
zstd 1.1.3 -1 2.877 430 MB/s 1110 MB/s
zlib 1.2.8 -1 2.743 110 MB/s 400 MB/s
brotli 0.5.2 -0 2.708 400 MB/s 430 MB/s
quicklz 1.5.0 -1 2.238 550 MB/s 710 MB/s
lzo1x 2.09 -1 2.108 650 MB/s 830 MB/s
lz4 1.7.5 2.101 720 MB/s 3600 MB/s
snappy 1.1.3 2.091 500 MB/s 1650 MB/s
lzf 3.6 -1 2.077 400 MB/s 860 MB/s
Minchan said:
: I did test with my sample data and compared zstd with deflate. zstd's
: compress ratio is lower a little bit but compression speed is much faster
: 3 times more and decompress speed is too 2 times more. With different
: data, it is different but overall, zstd would be better for speed at the
: cost of a little lower compress ratio(about 5%) so I believe it's worth to
: replace deflate.
[1] https://github.com/facebook/zstd
Link: http://lkml.kernel.org/r/20170912050005.3247-1-sergey.senozhatsky@gmail.com
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Tested-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[dwoo08.lee: backport upstream commit
5ef3a8b12556d to add zstd to zram compressor]
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
Change-Id: If4e2d781e5540300a57f9a93ef77360bd1c32e85
Dongwoo Lee [Wed, 3 Jun 2020 02:07:09 +0000 (11:07 +0900)]
arm64: tizen_tw3_defconfig: Enable ZSTD crypto
This enables zstd crypto for tw3 to support it as zram compressor.
Change-Id: I5cf2bd6c0b016e53023764c2a297c741f23eda6e
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
Nick Terrell [Thu, 3 Aug 2017 01:02:13 +0000 (18:02 -0700)]
crypto: Add zstd support
Adds zstd support to crypto and scompress. Only supports the default
level.
Previously we held off on this patch, since there weren't any users.
Now zram is ready for zstd support, but depends on CONFIG_CRYPTO_ZSTD,
which isn't defined until this patch is in. I also see a patch adding
zstd to pstore [0], which depends on crypto zstd.
[0] lkml.kernel.org/r/
9c9416b2dff19f05fb4c35879aaa83d11ff72c92.
1521626182.git.geliangtang@gmail.com
Signed-off-by: Nick Terrell <terrelln@fb.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
[dwoo08.lee: backport upstream commit
d28fc3dbe191 for applying zstd to zram]
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
Change-Id: I27969ec0cda2a6f6280ef6a10ee5cc33938032d1
Nick Terrell [Tue, 18 Jul 2017 00:08:19 +0000 (17:08 -0700)]
lib: Add zstd modules
Add zstd compression and decompression kernel modules.
zstd offers a wide varity of compression speed and quality trade-offs.
It can compress at speeds approaching lz4, and quality approaching lzma.
zstd decompressions at speeds more than twice as fast as zlib, and
decompression speed remains roughly the same across all compression levels.
The code was ported from the upstream zstd source repository. The
`linux/zstd.h` header was modified to match linux kernel style.
The cross-platform and allocation code was stripped out. Instead zstd
requires the caller to pass a preallocated workspace. The source files
were clang-formatted [1] to match the Linux Kernel style as much as
possible. Otherwise, the code was unmodified. We would like to avoid
as much further manual modification to the source code as possible, so it
will be easier to keep the kernel zstd up to date.
I benchmarked zstd compression as a special character device. I ran zstd
and zlib compression at several levels, as well as performing no
compression, which measure the time spent copying the data to kernel space.
Data is passed to the compresser 4096 B at a time. The benchmark file is
located in the upstream zstd source repository under
`contrib/linux-kernel/zstd_compress_test.c` [2].
I ran the benchmarks on a Ubuntu 14.04 VM with 2 cores and 4 GiB of RAM.
The VM is running on a MacBook Pro with a 3.1 GHz Intel Core i7 processor,
16 GB of RAM, and a SSD. I benchmarked using `silesia.tar` [3], which is
211,988,480 B large. Run the following commands for the benchmark:
sudo modprobe zstd_compress_test
sudo mknod zstd_compress_test c 245 0
sudo cp silesia.tar zstd_compress_test
The time is reported by the time of the userland `cp`.
The MB/s is computed with
1,536,217,008 B / time(buffer size, hash)
which includes the time to copy from userland.
The Adjusted MB/s is computed with
1,536,217,088 B / (time(buffer size, hash) - time(buffer size, none)).
The memory reported is the amount of memory the compressor requests.
| Method | Size (B) | Time (s) | Ratio | MB/s | Adj MB/s | Mem (MB) |
|----------|----------|----------|-------|---------|----------|----------|
| none |
11988480 | 0.100 | 1 | 2119.88 | - | - |
| zstd -1 |
73645762 | 1.044 | 2.878 | 203.05 | 224.56 | 1.23 |
| zstd -3 |
66988878 | 1.761 | 3.165 | 120.38 | 127.63 | 2.47 |
| zstd -5 |
65001259 | 2.563 | 3.261 | 82.71 | 86.07 | 2.86 |
| zstd -10 |
60165346 | 13.242 | 3.523 | 16.01 | 16.13 | 13.22 |
| zstd -15 |
58009756 | 47.601 | 3.654 | 4.45 | 4.46 | 21.61 |
| zstd -19 |
54014593 | 102.835 | 3.925 | 2.06 | 2.06 | 60.15 |
| zlib -1 |
77260026 | 2.895 | 2.744 | 73.23 | 75.85 | 0.27 |
| zlib -3 |
72972206 | 4.116 | 2.905 | 51.50 | 52.79 | 0.27 |
| zlib -6 |
68190360 | 9.633 | 3.109 | 22.01 | 22.24 | 0.27 |
| zlib -9 |
67613382 | 22.554 | 3.135 | 9.40 | 9.44 | 0.27 |
I benchmarked zstd decompression using the same method on the same machine.
The benchmark file is located in the upstream zstd repo under
`contrib/linux-kernel/zstd_decompress_test.c` [4]. The memory reported is
the amount of memory required to decompress data compressed with the given
compression level. If you know the maximum size of your input, you can
reduce the memory usage of decompression irrespective of the compression
level.
| Method | Time (s) | MB/s | Adjusted MB/s | Memory (MB) |
|----------|----------|---------|---------------|-------------|
| none | 0.025 | 8479.54 | - | - |
| zstd -1 | 0.358 | 592.15 | 636.60 | 0.84 |
| zstd -3 | 0.396 | 535.32 | 571.40 | 1.46 |
| zstd -5 | 0.396 | 535.32 | 571.40 | 1.46 |
| zstd -10 | 0.374 | 566.81 | 607.42 | 2.51 |
| zstd -15 | 0.379 | 559.34 | 598.84 | 4.61 |
| zstd -19 | 0.412 | 514.54 | 547.77 | 8.80 |
| zlib -1 | 0.940 | 225.52 | 231.68 | 0.04 |
| zlib -3 | 0.883 | 240.08 | 247.07 | 0.04 |
| zlib -6 | 0.844 | 251.17 | 258.84 | 0.04 |
| zlib -9 | 0.837 | 253.27 | 287.64 | 0.04 |
Tested in userland using the test-suite in the zstd repo under
`contrib/linux-kernel/test/UserlandTest.cpp` [5] by mocking the kernel
functions. Fuzz tested using libfuzzer [6] with the fuzz harnesses under
`contrib/linux-kernel/test/{RoundTripCrash.c,DecompressCrash.c}` [7] [8]
with ASAN, UBSAN, and MSAN. Additionaly, it was tested while testing the
BtrFS and SquashFS patches coming next.
[1] https://clang.llvm.org/docs/ClangFormat.html
[2] https://github.com/facebook/zstd/blob/dev/contrib/linux-kernel/zstd_compress_test.c
[3] http://sun.aei.polsl.pl/~sdeor/index.php?page=silesia
[4] https://github.com/facebook/zstd/blob/dev/contrib/linux-kernel/zstd_decompress_test.c
[5] https://github.com/facebook/zstd/blob/dev/contrib/linux-kernel/test/UserlandTest.cpp
[6] http://llvm.org/docs/LibFuzzer.html
[7] https://github.com/facebook/zstd/blob/dev/contrib/linux-kernel/test/RoundTripCrash.c
[8] https://github.com/facebook/zstd/blob/dev/contrib/linux-kernel/test/DecompressCrash.c
zstd source repository: https://github.com/facebook/zstd
Signed-off-by: Nick Terrell <terrelln@fb.com>
Signed-off-by: Chris Mason <clm@fb.com>
[dwoo08.lee: backport upstream commit
73f3d1b48f50]
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
Change-Id: I56d705828be2030b071b34d3eef4b7e56df98960
Nick Terrell [Tue, 18 Jul 2017 00:07:18 +0000 (17:07 -0700)]
lib: Add xxhash module
Adds xxhash kernel module with xxh32 and xxh64 hashes. xxhash is an
extremely fast non-cryptographic hash algorithm for checksumming.
The zstd compression and decompression modules added in the next patch
require xxhash. I extracted it out from zstd since it is useful on its
own. I copied the code from the upstream XXHash source repository and
translated it into kernel style. I ran benchmarks and tests in the kernel
and tests in userland.
I benchmarked xxhash as a special character device. I ran in four modes,
no-op, xxh32, xxh64, and crc32. The no-op mode simply copies the data to
kernel space and ignores it. The xxh32, xxh64, and crc32 modes compute
hashes on the copied data. I also ran it with four different buffer sizes.
The benchmark file is located in the upstream zstd source repository under
`contrib/linux-kernel/xxhash_test.c` [1].
I ran the benchmarks on a Ubuntu 14.04 VM with 2 cores and 4 GiB of RAM.
The VM is running on a MacBook Pro with a 3.1 GHz Intel Core i7 processor,
16 GB of RAM, and a SSD. I benchmarked using the file `filesystem.squashfs`
from `ubuntu-16.10-desktop-amd64.iso`, which is 1,536,217,088 B large.
Run the following commands for the benchmark:
modprobe xxhash_test
mknod xxhash_test c 245 0
time cp filesystem.squashfs xxhash_test
The time is reported by the time of the userland `cp`.
The GB/s is computed with
1,536,217,008 B / time(buffer size, hash)
which includes the time to copy from userland.
The Normalized GB/s is computed with
1,536,217,088 B / (time(buffer size, hash) - time(buffer size, none)).
| Buffer Size (B) | Hash | Time (s) | GB/s | Adjusted GB/s |
|-----------------|-------|----------|------|---------------|
| 1024 | none | 0.408 | 3.77 | - |
| 1024 | xxh32 | 0.649 | 2.37 | 6.37 |
| 1024 | xxh64 | 0.542 | 2.83 | 11.46 |
| 1024 | crc32 | 1.290 | 1.19 | 1.74 |
| 4096 | none | 0.380 | 4.04 | - |
| 4096 | xxh32 | 0.645 | 2.38 | 5.79 |
| 4096 | xxh64 | 0.500 | 3.07 | 12.80 |
| 4096 | crc32 | 1.168 | 1.32 | 1.95 |
| 8192 | none | 0.351 | 4.38 | - |
| 8192 | xxh32 | 0.614 | 2.50 | 5.84 |
| 8192 | xxh64 | 0.464 | 3.31 | 13.60 |
| 8192 | crc32 | 1.163 | 1.32 | 1.89 |
| 16384 | none | 0.346 | 4.43 | - |
| 16384 | xxh32 | 0.590 | 2.60 | 6.30 |
| 16384 | xxh64 | 0.466 | 3.30 | 12.80 |
| 16384 | crc32 | 1.183 | 1.30 | 1.84 |
Tested in userland using the test-suite in the zstd repo under
`contrib/linux-kernel/test/XXHashUserlandTest.cpp` [2] by mocking the
kernel functions. A line in each branch of every function in `xxhash.c`
was commented out to ensure that the test-suite fails. Additionally
tested while testing zstd and with SMHasher [3].
[1] https://phabricator.intern.facebook.com/P57526246
[2] https://github.com/facebook/zstd/blob/dev/contrib/linux-kernel/test/XXHashUserlandTest.cpp
[3] https://github.com/aappleby/smhasher
zstd source repository: https://github.com/facebook/zstd
XXHash source repository: https://github.com/cyan4973/xxhash
Signed-off-by: Nick Terrell <terrelln@fb.com>
Signed-off-by: Chris Mason <clm@fb.com>
[dwoo08.lee: backport from upstream commit
5d2405227a9e as base of zstd compaction library]
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
Change-Id: Id040bddd2c5661473ae16525453d17301e843d47
Giovanni Cabiddu [Fri, 21 Oct 2016 12:19:48 +0000 (13:19 +0100)]
crypto: acomp - add driver-side scomp interface
Add a synchronous back-end (scomp) to acomp. This allows to easily
expose the already present compression algorithms in LKCF via acomp.
Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
[dwoo08.lee: backport from upstream commit
1ab53a77b772 to apply xxhash and zstd]
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
Change-Id: Ic67e525fc5463875898e89fcbca903e1cdb122e1
Giovanni Cabiddu [Fri, 21 Oct 2016 12:19:47 +0000 (13:19 +0100)]
crypto: acomp - add asynchronous compression api
Add acomp, an asynchronous compression api that uses scatterlist
buffers.
Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
[dwoo08.lee: backport from upstream commit
2ebda74fd6c9 to apply xxhash and zstd]
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
Change-Id: Iab8381411103a6b8e9a5b8d3c4d5fe30c6893002
Deokhyun Kim [Mon, 4 May 2020 08:18:11 +0000 (17:18 +0900)]
Bluetooth: Add error handling logic of LE data batching
Change-Id: Idb111d65552ef484cdf5a5f4d795d94a2c165db9
Signed-off-by: Deokhyun Kim <dukan.kim@samsung.com>
Signed-off-by: Wootak Jung <wootak.jung@samsung.com>
jeongsup.jeong [Fri, 24 Apr 2020 10:08:09 +0000 (19:08 +0900)]
arm64: dts: tw3: use array for motor strength and frequency setting for multiple level
Add new properties data to devicetree in order to support
the new motor parameters.
Change-Id: I9358562f51557d71b1ec06037637604377d46179
Signed-off-by: jeongsup.jeong <jeongsup.jeong@samsung.com>
[cw00.choi: Add commit-msg as the public style]
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
jeongsup.jeong [Wed, 25 Mar 2020 10:30:57 +0000 (19:30 +0900)]
Motor: use default frequency when platform frequency request is predefined value, 0
Change the default value of frequency from 1 to 0 as following:
- 0 (Use default frequency)
- 1 ~ 8191 (0.1 ~ 819.1 Hz)
And check whether intensity_level is valid or in the early ztm620_motor_run()
function. The intensity_level should be less than count_strength and
count_frequency. The number of count_strength and count_frequency are fixed
according to the h/w device. Each h/w device specifies the number of
count_strength and count_frequency in their own devicetree.
Change-Id: Ia81cdcde06d670c916f32b5b105b5ade44dc016c
Signed-off-by: jeongsup.jeong <jeongsup.jeong@samsung.com>
[cw00.choi: Add commig-msg as the public style]
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
jeongsup.jeong [Fri, 27 Dec 2019 06:09:50 +0000 (15:09 +0900)]
Motor: change motor control parameters for new haptic concept
Change the motor control parameters which are used for communicating
between feedbackd in user-space and motor device driver in kernel.
[Detailed motor control parameters]
struct ff_rumble_effect {
__u16 strong_magnitude; // strong_magnitude[15:15] = 0 (Reserved)
// strong_magnitude[14:14]
// = Overdrive : 0 (Off) or 1 (On)
// strong_magnitude[13:0]
// = Intensity Value : 0 (Stop)
// or 1 ~ 10000 (Intensity)
__u16 weak_magnitude; // weak_magnitude[15:13]
// = Intensity Level : 1 ~ 5
// weak_magnitude[12:0]
// = Frequency in 0.1Hz : 0 ~ 8191 (0 ~ 819.1 Hz)
}; */
Change-Id: I3d65855086c2685ddaea3a494d2109f86a29cdbd
Signed-off-by: jeongsup.jeong <jeongsup.jeong@samsung.com>
[cw00.choi: Add commit-msg as the public style]
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
jeongsup.jeong [Mon, 22 Jul 2019 09:39:34 +0000 (18:39 +0900)]
Motor: add handling freq, overdrive param on ff effect
In order to handle the motor behavior in details,
add new 'frequency' and 'overdrive' parameter for ff (force feedback) effect.
Use the existing 'struct ff_runbm_effect' without any added variable
to pass the user data to input device driver of kernel.
Change-Id: I3f1e7ed8b280bdbfdf50bab7299d0f2b67ad3914
Signed-off-by: jeongsup.jeong <jeongsup.jeong@samsung.com>
[cw00.choi: Add commit-msg as public style and fix the merge conflict]
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
jeongsup.jeong [Thu, 13 Jun 2019 04:36:32 +0000 (13:36 +0900)]
Motor: ztm620: add motor status interface
Add exported ztm620_motor_is_running() function to inform the motor state
to outside of ztm620 device driver.
Change-Id: If9e1b42755d0b2c7d8c1f10d78746be58d011b6b
Signed-off-by: jeongsup.jeong <jeongsup.jeong@samsung.com>
[cw00.choi: Add commit-msg as the public style]
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
woochul.shin [Wed, 6 May 2020 09:56:00 +0000 (18:56 +0900)]
motor: ztm620: set dc motor dt and add switch motor type
Modify the motor data such as motor_start_data and motor_stop_dat
according to the motor type. Each h/w device is able to select
the their own motor type in devicetree.
Example of the motor type,
- TW3's motor type is LRA
Change-Id: I2d2f830ff787ab7a9d5f042a0a7ba139b4401258
Signed-off-by: woochul.shin <woochul.shin@samsung.com>
[cw00.choi: Add commig-msg as the public style]
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
jeongsup.jeong [Tue, 20 Nov 2018 04:50:58 +0000 (13:50 +0900)]
Motor: ztm620: add pm_notifier
Add PM Notifier in order to control the state of motor device.
When PM_SUSPEND_PREPARE, disable the motor and in case of PM_POST_SUSPEND,
enable motor device. And do refactor the code for the readability.
Change-Id: I2e51fab75d5fcf5dc16b0eabd5212d4fb5a75540
Signed-off-by: jeongsup.jeong <jeongsup.jeong@samsung.com>
[cw00.choi: Add commig-msg as the public style]
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Dongwoo Lee [Fri, 8 May 2020 06:30:40 +0000 (15:30 +0900)]
usb: gadget: f_fs: Limit data buffer size to a single page
Large size request from sdbd usually causes memory allocation failure
in case of memory shortage. The failure is not handled by sdbd
properly and thus it makes sdbd a hung state. To prevent this
situation, this patch limits data buffer size to a single page so as
to guarantee memory allocation success.
Change-Id: I4eada6c8beca337cf93182b6d860209cc80d044d
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
Dongwoo Lee [Fri, 8 May 2020 06:50:04 +0000 (15:50 +0900)]
Revert "usb: gadget: f_fs: Give chance to retry malloc for large size buffer"
This reverts commit
868788459b5403009d82575fd4834efbfe11e7b2.
That commit turns out that causing write (in transfer) failure when
buffer allocation is failed due to memory shortage. So, it reveals
multiple tries is not complete solution.
Change-Id: Ie924272060dd689e378c59fdca1ea2ddfa571fb2
Reported-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
Wootak Jung [Wed, 1 Apr 2020 02:52:54 +0000 (11:52 +0900)]
Bluetooth: Add GATT data batching
GATT batching is a function to reduce the AP's wake every time it receives the
GATT data. If user set the timeout or threshold of the number of data packets
and correspond to one condition, the collected data will be raised in order.
Change-Id: I6968b73bd562a3b7a382f3253bb04dfcef399b57
Signed-off-by: Deokhyun Kim <dukan.kim@samsung.com>
Signed-off-by: Wootak Jung <wootak.jung@samsung.com>
lsmin.lee [Fri, 3 Jan 2020 09:31:42 +0000 (18:31 +0900)]
Input: tizen_bezel: Change event value of the bezel device
Until Tizen 5.0, for bezel input device, its event value was in
between -2 and 2, but value 1. meant starting movement to
counter clockwiseare or clockwise, and value -1, meant moving back
to original position, never used. Change event value of the bezel
device for Tizen 5.5 and later version.
It changes bezel input driver event interface, so user input
framework for bezel input should be also changed.
Ref: https://review.tizen.org/gerrit/#/c/platform/upstream/enlightenment/+/220346/
Signed-off-by: lsmin.lee <lsmin.lee@samsung.com>
[sw0312.kim: adjust commit-msg to public style]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I1293db138c71d2a5c4f52b827f3a441b47710449
Matias Karhumaa [Wed, 26 Sep 2018 06:13:46 +0000 (09:13 +0300)]
Bluetooth: SMP: fix crash in unpairing
[ Upstream commit
cb28c306b93b71f2741ce1a5a66289db26715f4d ]
In case unpair_device() was called through mgmt interface at the same time
when pairing was in progress, Bluetooth kernel module crash was seen.
[ 600.351225] general protection fault: 0000 [#1] SMP PTI
[ 600.351235] CPU: 1 PID: 11096 Comm: btmgmt Tainted: G OE 4.19.0-rc1+ #1
[ 600.351238] Hardware name: Dell Inc. Latitude E5440/08RCYC, BIOS A18 05/14/2017
[ 600.351272] RIP: 0010:smp_chan_destroy.isra.10+0xce/0x2c0 [bluetooth]
[ 600.351276] Code: c0 0f 84 b4 01 00 00 80 78 28 04 0f 84 53 01 00 00 4d 85 ed 0f 85 ab 00 00 00 48 8b 08 48 8b 50 08 be 10 00 00 00 48 89 51 08 <48> 89 0a 48 b9 00 02 00 00 00 00 ad de 48 89 48 08 48 8b 83 00 01
[ 600.351279] RSP: 0018:
ffffa9be839b3b50 EFLAGS:
00010246
[ 600.351282] RAX:
ffff9c999ac565a0 RBX:
ffff9c9996e98c00 RCX:
ffff9c999aa28b60
[ 600.351285] RDX:
dead000000000200 RSI:
0000000000000010 RDI:
ffff9c999e403500
[ 600.351287] RBP:
ffffa9be839b3b70 R08:
0000000000000000 R09:
ffffffff92a25c00
[ 600.351290] R10:
ffffa9be839b3ae8 R11:
0000000000000001 R12:
ffff9c995375b800
[ 600.351292] R13:
0000000000000000 R14:
ffff9c99619a5000 R15:
ffff9c9962a01c00
[ 600.351295] FS:
00007fb2be27c700(0000) GS:
ffff9c999e880000(0000) knlGS:
0000000000000000
[ 600.351298] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 600.351300] CR2:
00007fb2bdadbad0 CR3:
000000041c328001 CR4:
00000000001606e0
[ 600.351302] Call Trace:
[ 600.351325] smp_failure+0x4f/0x70 [bluetooth]
[ 600.351345] smp_cancel_pairing+0x74/0x80 [bluetooth]
[ 600.351370] unpair_device+0x1c1/0x330 [bluetooth]
[ 600.351399] hci_sock_sendmsg+0x960/0x9f0 [bluetooth]
[ 600.351409] ? apparmor_socket_sendmsg+0x1e/0x20
[ 600.351417] sock_sendmsg+0x3e/0x50
[ 600.351422] sock_write_iter+0x85/0xf0
[ 600.351429] do_iter_readv_writev+0x12b/0x1b0
[ 600.351434] do_iter_write+0x87/0x1a0
[ 600.351439] vfs_writev+0x98/0x110
[ 600.351443] ? ep_poll+0x16d/0x3d0
[ 600.351447] ? ep_modify+0x73/0x170
[ 600.351451] do_writev+0x61/0xf0
[ 600.351455] ? do_writev+0x61/0xf0
[ 600.351460] __x64_sys_writev+0x1c/0x20
[ 600.351465] do_syscall_64+0x5a/0x110
[ 600.351471] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 600.351474] RIP: 0033:0x7fb2bdb62fe0
[ 600.351477] Code: 73 01 c3 48 8b 0d b8 6e 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 69 c7 2c 00 00 75 10 b8 14 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 de 80 01 00 48 89 04 24
[ 600.351479] RSP: 002b:
00007ffe062cb8f8 EFLAGS:
00000246 ORIG_RAX:
0000000000000014
[ 600.351484] RAX:
ffffffffffffffda RBX:
000000000255b3d0 RCX:
00007fb2bdb62fe0
[ 600.351487] RDX:
0000000000000001 RSI:
00007ffe062cb920 RDI:
0000000000000004
[ 600.351490] RBP:
00007ffe062cb920 R08:
000000000255bd80 R09:
0000000000000000
[ 600.351494] R10:
0000000000000353 R11:
0000000000000246 R12:
0000000000000001
[ 600.351497] R13:
00007ffe062cbbe0 R14:
0000000000000000 R15:
0000000000000000
[ 600.351501] Modules linked in: algif_hash algif_skcipher af_alg cmac ipt_MASQUERADE nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo iptable_nat nf_nat_ipv4 xt_addrtype iptable_filter ip_tables xt_conntrack x_tables nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c br_netfilter bridge stp llc overlay arc4 nls_iso8859_1 dm_crypt intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp dell_laptop kvm_intel crct10dif_pclmul dell_smm_hwmon crc32_pclmul ghash_clmulni_intel pcbc aesni_intel aes_x86_64 crypto_simd cryptd glue_helper intel_cstate intel_rapl_perf uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev media hid_multitouch input_leds joydev serio_raw dell_wmi snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic dell_smbios dcdbas sparse_keymap
[ 600.351569] snd_hda_intel btusb snd_hda_codec btrtl btbcm btintel snd_hda_core bluetooth(OE) snd_hwdep snd_pcm iwlmvm ecdh_generic wmi_bmof dell_wmi_descriptor snd_seq_midi mac80211 snd_seq_midi_event lpc_ich iwlwifi snd_rawmidi snd_seq snd_seq_device snd_timer cfg80211 snd soundcore mei_me mei dell_rbtn dell_smo8800 mac_hid parport_pc ppdev lp parport autofs4 hid_generic usbhid hid i915 nouveau kvmgt vfio_mdev mdev vfio_iommu_type1 vfio kvm irqbypass i2c_algo_bit ttm drm_kms_helper syscopyarea sysfillrect sysimgblt mxm_wmi psmouse ahci sdhci_pci cqhci libahci fb_sys_fops sdhci drm e1000e video wmi
[ 600.351637] ---[ end trace
e49e9f1df09c94fb ]---
[ 600.351664] RIP: 0010:smp_chan_destroy.isra.10+0xce/0x2c0 [bluetooth]
[ 600.351666] Code: c0 0f 84 b4 01 00 00 80 78 28 04 0f 84 53 01 00 00 4d 85 ed 0f 85 ab 00 00 00 48 8b 08 48 8b 50 08 be 10 00 00 00 48 89 51 08 <48> 89 0a 48 b9 00 02 00 00 00 00 ad de 48 89 48 08 48 8b 83 00 01
[ 600.351669] RSP: 0018:
ffffa9be839b3b50 EFLAGS:
00010246
[ 600.351672] RAX:
ffff9c999ac565a0 RBX:
ffff9c9996e98c00 RCX:
ffff9c999aa28b60
[ 600.351674] RDX:
dead000000000200 RSI:
0000000000000010 RDI:
ffff9c999e403500
[ 600.351676] RBP:
ffffa9be839b3b70 R08:
0000000000000000 R09:
ffffffff92a25c00
[ 600.351679] R10:
ffffa9be839b3ae8 R11:
0000000000000001 R12:
ffff9c995375b800
[ 600.351681] R13:
0000000000000000 R14:
ffff9c99619a5000 R15:
ffff9c9962a01c00
[ 600.351684] FS:
00007fb2be27c700(0000) GS:
ffff9c999e880000(0000) knlGS:
0000000000000000
[ 600.351686] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 600.351689] CR2:
00007fb2bdadbad0 CR3:
000000041c328001 CR4:
00000000001606e0
Crash happened because list_del_rcu() was called twice for smp->ltk. This
was possible if unpair_device was called right after ltk was generated
but before keys were distributed.
In this commit smp_cancel_pairing was refactored to cancel pairing if it
is in progress and otherwise just removes keys. Once keys are removed from
rcu list, pointers to smp context's keys are set to NULL to make sure
removed list items are not accessed later.
This commit also adjusts the functionality of mgmt unpair_device() little
bit. Previously pairing was canceled only if pairing was in state that
keys were already generated. With this commit unpair_device() cancels
pairing already in earlier states.
Bug was found by fuzzing kernel SMP implementation using Synopsys
Defensics.
Reported-by: Pekka Oikarainen <pekka.oikarainen@synopsys.com>
Signed-off-by: Matias Karhumaa <matias.karhumaa@gmail.com>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[dh79.pyun: apply mainline stable linux-4.9.y commit
83e158f93d66 to handle BT crash issue]
Signed-off-by: DoHyun Pyun <dh79.pyun@samsung.com>
Change-Id: Iaa7196d5bb49fe993ba9ca0bf9b9a1eece7b6200
Szymon Janc [Mon, 26 Feb 2018 14:41:53 +0000 (15:41 +0100)]
Bluetooth: Fix missing encryption refresh on Security Request
commit
64e759f58f128730b97a3c3a26d283c075ad7c86 upstream.
If Security Request is received on connection that is already encrypted
with sufficient security master should perform encryption key refresh
procedure instead of just ignoring Slave Security Request
(Core Spec 5.0 Vol 3 Part H 2.4.6).
> ACL Data RX: Handle 3585 flags 0x02 dlen 6
SMP: Security Request (0x0b) len 1
Authentication requirement: Bonding, No MITM, SC, No Keypresses (0x09)
< HCI Command: LE Start Encryption (0x08|0x0019) plen 28
Handle: 3585
Random number: 0x0000000000000000
Encrypted diversifier: 0x0000
Long term key:
44264272a5c426a9e868f034cf0e69f3
> HCI Event: Command Status (0x0f) plen 4
LE Start Encryption (0x08|0x0019) ncmd 1
Status: Success (0x00)
> HCI Event: Encryption Key Refresh Complete (0x30) plen 3
Status: Success (0x00)
Handle: 3585
Signed-off-by: Szymon Janc <szymon.janc@codecoup.pl>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[dh79.pyun: apply mainline stable linux-4.9.y commit
24382a60331d to handle BT issue]
Signed-off-by: DoHyun Pyun <dh79.pyun@samsung.com>
Change-Id: Ifb94f389253d8515bcc4676fffcfd73c09f1242c
Ard Biesheuvel [Mon, 3 Dec 2018 19:58:05 +0000 (20:58 +0100)]
arm64: relocatable: fix inconsistencies in linker script and options
commit
3bbd3db86470c701091fb1d67f1fab6621debf50 upstream.
readelf complains about the section layout of vmlinux when building
with CONFIG_RELOCATABLE=y (for KASLR):
readelf: Warning: [21]: Link field (0) should index a symtab section.
readelf: Warning: [21]: Info field (0) should index a relocatable section.
Also, it seems that our use of '-pie -shared' is contradictory, and
thus ambiguous. In general, the way KASLR is wired up at the moment
is highly tailored to how ld.bfd happens to implement (and conflate)
PIE executables and shared libraries, so given the current effort to
support other toolchains, let's fix some of these issues as well.
- Drop the -pie linker argument and just leave -shared. In ld.bfd,
the differences between them are unclear (except for the ELF type
of the produced image [0]) but lld chokes on seeing both at the
same time.
- Rename the .rela output section to .rela.dyn, as is customary for
shared libraries and PIE executables, so that it is not misidentified
by readelf as a static relocation section (producing the warnings
above).
- Pass the -z notext and -z norelro options to explicitly instruct the
linker to permit text relocations, and to omit the RELRO program
header (which requires a certain section layout that we don't adhere
to in the kernel). These are the defaults for current versions of
ld.bfd.
- Discard .eh_frame and .gnu.hash sections to avoid them from being
emitted between .head.text and .text, screwing up the section layout.
These changes only affect the ELF image, and produce the same binary
image.
[0]
b9dce7f1ba01 ("arm64: kernel: force ET_DYN ELF type for ...")
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Peter Smith <peter.smith@linaro.org>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Found solution for Tizen 6.0 toolchain by Mikhail Kashkarov <m.kashkarov@partner.samsung.com> ]
[sw0312.kim: backport stable linux-4.14.y commit
f21ce3cdff2f for gcc 9 built image]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I0ddfedad20188dcd9d7b416370e95d175b595db0
Greg Hackmann [Tue, 27 Nov 2018 19:15:20 +0000 (11:15 -0800)]
arm64: remove no-op -p linker flag
(commit
1a381d4a0a9a0f999a13faaba22bf6b3fc80dcb9 upstream)
Linking the ARM64 defconfig kernel with LLVM lld fails with the error:
ld.lld: error: unknown argument: -p
Makefile:1015: recipe for target 'vmlinux' failed
Without this flag, the ARM64 defconfig kernel successfully links with
lld and boots on Dragonboard 410c.
After digging through binutils source and changelogs, it turns out that
-p is only relevant to ancient binutils installations targeting 32-bit
ARM. binutils accepts -p for AArch64 too, but it's always been
undocumented and silently ignored. A comment in
ld/emultempl/aarch64elf.em explains that it's "Only here for backwards
compatibility".
Since this flag is a no-op on ARM64, we can safely drop it.
Acked-by: Will Deacon <will.deacon@arm.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Greg Hackmann <ghackmann@google.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[sw0312.kim: cherry-pick stable linux-4.9.y commit
272991176af2 for gcc 9 build]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I47c82851c886f2b1d3af3e65ef7e7131ea877b62
Nick Desaulniers [Fri, 27 Oct 2017 16:33:41 +0000 (09:33 -0700)]
arm64: prevent regressions in compressed kernel image size when upgrading to binutils 2.27
[ Upstream commit
fd9dde6abcb9bfe6c6bee48834e157999f113971 ]
Upon upgrading to binutils 2.27, we found that our lz4 and gzip
compressed kernel images were significantly larger, resulting is 10ms
boot time regressions.
As noted by Rahul:
"aarch64 binaries uses RELA relocations, where each relocation entry
includes an addend value. This is similar to x86_64. On x86_64, the
addend values are also stored at the relocation offset for relative
relocations. This is an optimization: in the case where code does not
need to be relocated, the loader can simply skip processing relative
relocations. In binutils-2.25, both bfd and gold linkers did this for
x86_64, but only the gold linker did this for aarch64. The kernel build
here is using the bfd linker, which stored zeroes at the relocation
offsets for relative relocations. Since a set of zeroes compresses
better than a set of non-zero addend values, this behavior was resulting
in much better lz4 compression.
The bfd linker in binutils-2.27 is now storing the actual addend values
at the relocation offsets. The behavior is now consistent with what it
does for x86_64 and what gold linker does for both architectures. The
change happened in this upstream commit:
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=
1f56df9d0d5ad89806c24e71f296576d82344613
Since a bunch of zeroes got replaced by non-zero addend values, we see
the side effect of lz4 compressed image being a bit bigger.
To get the old behavior from the bfd linker, "--no-apply-dynamic-relocs"
flag can be used:
$ LDFLAGS="--no-apply-dynamic-relocs" make
With this flag, the compressed image size is back to what it was with
binutils-2.25.
If the kernel is using ASLR, there aren't additional runtime costs to
--no-apply-dynamic-relocs, as the relocations will need to be applied
again anyway after the kernel is relocated to a random address.
If the kernel is not using ASLR, then presumably the current default
behavior of the linker is better. Since the static linker performed the
dynamic relocs, and the kernel is not moved to a different address at
load time, it can skip applying the relocations all over again."
Some measurements:
$ ld -v
GNU ld (binutils-2.25-
f3d35cf6) 2.25.51.
20141117
^
$ ls -l vmlinux
-rwxr-x--- 1 ndesaulniers eng
300652760 Oct 26 11:57 vmlinux
$ ls -l Image.lz4-dtb
-rw-r----- 1 ndesaulniers eng
16932627 Oct 26 11:57 Image.lz4-dtb
$ ld -v
GNU ld (binutils-2.27-
53dd00a1) 2.27.0.
20170315
^
pre patch:
$ ls -l vmlinux
-rwxr-x--- 1 ndesaulniers eng
300376208 Oct 26 11:43 vmlinux
$ ls -l Image.lz4-dtb
-rw-r----- 1 ndesaulniers eng
18159474 Oct 26 11:43 Image.lz4-dtb
post patch:
$ ls -l vmlinux
-rwxr-x--- 1 ndesaulniers eng
300376208 Oct 26 12:06 vmlinux
$ ls -l Image.lz4-dtb
-rw-r----- 1 ndesaulniers eng
16932466 Oct 26 12:06 Image.lz4-dtb
By Siqi's measurement w/ gzip:
binutils 2.27 with this patch (with --no-apply-dynamic-relocs):
Image
41535488
Image.gz
13404067
binutils 2.27 without this patch (without --no-apply-dynamic-relocs):
Image
41535488
Image.gz
14125516
Any compression scheme should be able to get better results from the
longer runs of zeros, not just GZIP and LZ4.
10ms boot time savings isn't anything to get excited about, but users of
arm64+compression+bfd-2.27 should not have to pay a penalty for no
runtime improvement.
Reported-by: Gopinath Elanchezhian <gelanchezhian@google.com>
Reported-by: Sindhuri Pentyala <spentyala@google.com>
Reported-by: Wei Wang <wvw@google.com>
Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Suggested-by: Rahul Chaudhry <rahulchaudhry@google.com>
Suggested-by: Siqi Lin <siqilin@google.com>
Suggested-by: Stephen Hines <srhines@google.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
[will: added comment to Makefile]
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[sw0312.kim: cherry-pick stable linux-4.9.y commit
b7ada2c0ea29 for gcc 9 build]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I1b1afff5c639be9ab429f23b38b144c9cc8a7240
Nathan Chancellor [Tue, 11 Jun 2019 17:19:32 +0000 (10:19 -0700)]
arm64: Don't unconditionally add -Wno-psabi to KBUILD_CFLAGS
This is a GCC only option, which warns about ABI changes within GCC, so
unconditionally adding it breaks Clang with tons of:
warning: unknown warning option '-Wno-psabi' [-Wunknown-warning-option]
and link time failures:
ld.lld: error: undefined symbol: __efistub___stack_chk_guard
>>> referenced by arm-stub.c:73
(/home/nathan/cbl/linux/drivers/firmware/efi/libstub/arm-stub.c:73)
>>> arm-stub.stub.o:(__efistub_install_memreserve_table)
in archive ./drivers/firmware/efi/libstub/lib.a
These failures come from the lack of -fno-stack-protector, which is
added via cc-option in drivers/firmware/efi/libstub/Makefile. When an
unknown flag is added to KBUILD_CFLAGS, clang will noisily warn that it
is ignoring the option like above, unlike gcc, who will just error.
$ echo "int main() { return 0; }" > tmp.c
$ clang -Wno-psabi tmp.c; echo $?
warning: unknown warning option '-Wno-psabi' [-Wunknown-warning-option]
1 warning generated.
0
$ gcc -Wsometimes-uninitialized tmp.c; echo $?
gcc: error: unrecognized command line option
‘-Wsometimes-uninitialized’; did you mean ‘-Wmaybe-uninitialized’?
1
For cc-option to work properly with clang and behave like gcc, -Werror
is needed, which was done in commit
c3f0d0bc5b01 ("kbuild, LLVMLinux:
Add -Werror to cc-option to support clang").
$ clang -Werror -Wno-psabi tmp.c; echo $?
error: unknown warning option '-Wno-psabi'
[-Werror,-Wunknown-warning-option]
1
As a consequence of this, when an unknown flag is unconditionally added
to KBUILD_CFLAGS, it will cause cc-option to always fail and those flags
will never get added:
$ clang -Werror -Wno-psabi -fno-stack-protector tmp.c; echo $?
error: unknown warning option '-Wno-psabi'
[-Werror,-Wunknown-warning-option]
1
This can be seen when compiling the whole kernel as some warnings that
are normally disabled (see below) show up. The full list of flags
missing from drivers/firmware/efi/libstub are the following (gathered
from diffing .arm64-stub.o.cmd):
-fno-delete-null-pointer-checks
-Wno-address-of-packed-member
-Wframe-larger-than=2048
-Wno-unused-const-variable
-fno-strict-overflow
-fno-merge-all-constants
-fno-stack-check
-Werror=date-time
-Werror=incompatible-pointer-types
-ffreestanding
-fno-stack-protector
Use cc-disable-warning so that it gets disabled for GCC and does nothing
for Clang.
Fixes:
ebcc5928c5d9 ("arm64: Silence gcc warnings about arch ABI drift")
Link: https://github.com/ClangBuiltLinux/linux/issues/511
Reported-by: Qian Cai <cai@lca.pw>
Acked-by: Dave Martin <Dave.Martin@arm.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
[sw0312.kim: backport mainline commit
fa63da2ab046 for gcc 9 build]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I4b6f775dd115a8eb92080c570b7727c143ede17c
Dave Martin [Thu, 6 Jun 2019 10:33:43 +0000 (11:33 +0100)]
arm64: Silence gcc warnings about arch ABI drift
Since GCC 9, the compiler warns about evolution of the
platform-specific ABI, in particular relating for the marshaling of
certain structures involving bitfields.
The kernel is a standalone binary, and of course nobody would be
so stupid as to expose structs containing bitfields as function
arguments in ABI. (Passing a pointer to such a struct, however
inadvisable, should be unaffected by this change. perf and various
drivers rely on that.)
So these warnings do more harm than good: turn them off.
We may miss warnings about future ABI drift, but that's too bad.
Future ABI breaks of this class will have to be debugged and fixed
the traditional way unless the compiler evolves finer-grained
diagnostics.
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
[sw0312.kim: backport mainline commit
ebcc5928c5d9 for gcc 9 build]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: Ic7620fb77291c55e8237495d99285c8a14eac326
Seung-Woo Kim [Mon, 23 Dec 2019 10:48:32 +0000 (19:48 +0900)]
Input: zxt_ztm620_ts: Remove possible overflow by using strlcat()
The strncat() from a buffer to other buffer with same size can
make overflow. Remove the possible overflow by replacing strncat()
to strlcat().
Change-Id: I2d98f7548c87e048726bf4c3dc7ed942270565d9
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Seung-Woo Kim [Mon, 23 Dec 2019 10:01:44 +0000 (19:01 +0900)]
Input: zxt_ztm620_ts: Repalce meaningless strncat() to strcat()
The strncat() with length from strlen() of copied string is
completely meaningless. Just replace the usage of strncat() to
strcat().
Change-Id: Ibdd75a6cc7d5e2f9e80f20535f7d61b278fc29a3
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Seung-Woo Kim [Mon, 23 Dec 2019 08:23:37 +0000 (17:23 +0900)]
soc: samsung: cal-if: fix not to calculate array size from null
Calculating array size from null causes sizeof-pointer-div warning.
Fix not to calculate array size from null by adding pll macro
without NULL array.
Change-Id: I7002376523bd42cedaebc6443135c8410e5a1c46
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Seung-Woo Kim [Mon, 23 Dec 2019 08:29:02 +0000 (17:29 +0900)]
video: fbdev: exynos: dpu9110: panel: s6e36w3x01: remove buffer overflow
The memcpy to buffer has out of bounds for array. Remove the
buffer overflow for by adding additional array length.
Change-Id: I0aa5974fd39a6a7f705740ce1dcbf6ce15c2e935
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Seung-Woo Kim [Mon, 23 Dec 2019 07:20:00 +0000 (16:20 +0900)]
AsoC: speedy: fix sizeof-pointer-memaccess for strncpy()
The strncpy() is done with sizeof() for source. Fix warning from
sizeof-pointer-memaccess by replacing sizeof() for destination.
Change-Id: I2e4bbdda84e90391d8767358ebebb12bdc10154e
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Seung-Woo Kim [Mon, 23 Dec 2019 07:58:25 +0000 (16:58 +0900)]
net: bcmdhd: Fix string concatenate with strncat()
There is stringop-overflow warning to use strncat and bound check
for buffer size for the string is already done. Fix string
concatenate with strncat() by replacing with strcat().
Change-Id: I8c009e4d76f5044601bacd596d4ca872bb69fd1f
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Anupam Roy [Thu, 26 Dec 2019 11:26:02 +0000 (16:56 +0530)]
arm64: tizen_tw3_defconfig: Enable CONFIG_CRYPTO_CCM
Enable CONFIG_CRYPTO_CCM config option for using
AEAD-AES_CCM encryption. AEAD socket with
AES_CCM cipher type is used by Bluetooth Mesh
functionality for encryption & decryption.
Change-Id: I8b940288c2763ebc3007d5a419329f392b41ad8b
Signed-off-by: Anupam Roy <anupam.r@samsung.com>
Seung-Woo Kim [Fri, 27 Dec 2019 00:59:16 +0000 (09:59 +0900)]
arm64: tizen_tw3_defconfig: sync USB_CONFIGFS related config options
After CONFIG_USB_CONFIGFS is enabled, defconfig was not fully
updated. Sync realted config options.
Change-Id: I96c99483933f0c84bd48b0f67110a469bf245ef7
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Matthias Kaehlcke [Thu, 13 Apr 2017 17:05:04 +0000 (10:05 -0700)]
cfg80211: Fix array-bounds warning in fragment copy
commit
aa1702dd162f420bf85ecef0c77686ef0dbc1496 upstream.
__ieee80211_amsdu_copy_frag intentionally initializes a pointer to
array[-1] to increment it later to valid values. clang rightfully
generates an array-bounds warning on the initialization statement.
Initialize the pointer to array[0] and change the algorithm from
increment before to increment after consume.
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Cc: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[sw0312.kim: cherry-pick stable linux-4.9.y commit
4bb797afd7ba for gcc 9 build]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: Ibb581c74dc67fcc867f7fa58d20cb1b225caa852
Sultan Alsawaf [Wed, 6 Jun 2018 22:56:54 +0000 (15:56 -0700)]
ip_tunnel: Fix name string concatenate in __ip_tunnel_create()
commit
000ade8016400d93b4d7c89970d96b8c14773d45 upstream.
By passing a limit of 2 bytes to strncat, strncat is limited to writing
fewer bytes than what it's supposed to append to the name here.
Since the bounds are checked on the line above this, just remove the string
bounds checks entirely since they're unneeded.
Signed-off-by: Sultan Alsawaf <sultanxda@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[sw0312.kim: cherry-pick stable linux-4.9.y commit
5569c10858be for gcc 9 build]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: Ida4f04d469c4d91f12faa5fe46bd443c43bfe333
Miguel Ojeda [Thu, 23 May 2019 12:45:35 +0000 (14:45 +0200)]
tracing: Silence GCC 9 array bounds warning
commit
0c97bf863efce63d6ab7971dad811601e6171d2f upstream.
Starting with GCC 9, -Warray-bounds detects cases when memset is called
starting on a member of a struct but the size to be cleared ends up
writing over further members.
Such a call happens in the trace code to clear, at once, all members
after and including `seq` on struct trace_iterator:
In function 'memset',
inlined from 'ftrace_dump' at kernel/trace/trace.c:8914:3:
./include/linux/string.h:344:9: warning: '__builtin_memset' offset
[8505, 8560] from the object at 'iter' is out of the bounds of
referenced subobject 'seq' with type 'struct trace_seq' at offset
4368 [-Warray-bounds]
344 | return __builtin_memset(p, c, size);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
In order to avoid GCC complaining about it, we compute the address
ourselves by adding the offsetof distance instead of referring
directly to the member.
Since there are two places doing this clear (trace.c and trace_kdb.c),
take the chance to move the workaround into a single place in
the internal header.
Link: http://lkml.kernel.org/r/20190523124535.GA12931@gmail.com
Signed-off-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
[ Removed unnecessary parenthesis around "iter" ]
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[sw0312.kim: cherry-pick stable linux-4.9.y commit
2e41539ee26f for gcc 9 build]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I82d986a1e1a6a447c2fd3b5c3af3145192e72748
Linus Torvalds [Wed, 1 May 2019 18:05:41 +0000 (11:05 -0700)]
gcc-9: silence 'address-of-packed-member' warning
commit
6f303d60534c46aa1a239f29c321f95c83dda748 upstream.
We already did this for clang, but now gcc has that warning too. Yes,
yes, the address may be unaligned. And that's kind of the point.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[sw0312.kim: cherry-pick stable linux-4.9.y commit
7601d81506ef for gcc 9 build]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: Id774c5d5a37b7761a7792be0fedc7282f19d45f8
Linus Torvalds [Fri, 30 Nov 2018 22:45:01 +0000 (14:45 -0800)]
unifdef: use memcpy instead of strncpy
commit
38c7b224ce22c25fed04007839edf974bd13439d upstream.
New versions of gcc reasonably warn about the odd pattern of
strncpy(p, q, strlen(q));
which really doesn't make sense: the strncpy() ends up being just a slow
and odd way to write memcpy() in this case.
There was a comment about _why_ the code used strncpy - to avoid the
terminating NUL byte, but memcpy does the same and avoids the warning.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[sw0312.kim: cherry-pick stable linux-4.9.y commit
0d4a2de44713 for gcc 9 build]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I3adb0d708af7d8a55216d6c81d1e691b8d30e8c1
Kees Cook [Fri, 5 Jul 2019 18:47:20 +0000 (20:47 +0200)]
arm64, vdso: Define vdso_{start,end} as array
Commit
dbbb08f500d6146398b794fdc68a8e811366b451 upstream.
Adjust vdso_{start|end} to be char arrays to avoid compile-time analysis
that flags "too large" memcmp() calls with CONFIG_FORTIFY_SOURCE.
Cc: Jisheng Zhang <jszhang@marvell.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Suggested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[sw0312.kim: cherry-pick stable linux-4.9.y commit
830d3a71e1ce for gcc 9 build]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I32aa68e1365d0389f05ab456f82b3b72f10b60da
Xiongfeng Wang [Thu, 11 Jan 2018 09:22:29 +0000 (17:22 +0800)]
Kbuild: suppress packed-not-aligned warning for default setting only
commit
321cb0308a9e76841394b4bbab6a1107cfedbae0 upstream.
gcc-8 reports many -Wpacked-not-aligned warnings. The below are some
examples.
./include/linux/ceph/msgr.h:67:1: warning: alignment 1 of 'struct
ceph_entity_addr' is less than 8 [-Wpacked-not-aligned]
} __attribute__ ((packed));
./include/linux/ceph/msgr.h:67:1: warning: alignment 1 of 'struct
ceph_entity_addr' is less than 8 [-Wpacked-not-aligned]
} __attribute__ ((packed));
./include/linux/ceph/msgr.h:67:1: warning: alignment 1 of 'struct
ceph_entity_addr' is less than 8 [-Wpacked-not-aligned]
} __attribute__ ((packed));
This patch suppresses this kind of warnings for default setting.
Signed-off-by: Xiongfeng Wang <xiongfeng.wang@linaro.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[sw0312.kim: cherry-pick stable linux-4.9.y commit
dfb64b8c3d26 for gcc 9 build]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I9fe83e410fbf2ddd0ce52842ed1f5c24efce260a
Stephen Rothwell [Thu, 30 Aug 2018 21:47:28 +0000 (07:47 +1000)]
disable stringop truncation warnings for now
commit
217c3e0196758662aa0429863b09d1c13da1c5d6 upstream.
They are too noisy
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[sw0312.kim: cherry-pick stable linux-4.9.y commit
5e2669c978b2 for gcc 9 build]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I57286951ce59491105cc89ec99277a180b3c7478
Nathan Chancellor [Sat, 2 Jun 2018 16:02:09 +0000 (09:02 -0700)]
kconfig: Avoid format overflow warning from GCC 8.1
commit
2ae89c7a82ea9d81a19b4fc2df23bef4b112f24e upstream.
In file included from scripts/kconfig/zconf.tab.c:2485:
scripts/kconfig/confdata.c: In function ‘conf_write’:
scripts/kconfig/confdata.c:773:22: warning: ‘%s’ directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
sprintf(newname, "%s%s", dirname, basename);
^~
scripts/kconfig/confdata.c:773:19: note: assuming directive output of 7 bytes
sprintf(newname, "%s%s", dirname, basename);
^~~~~~
scripts/kconfig/confdata.c:773:2: note: ‘sprintf’ output 1 or more bytes (assuming 4104) into a destination of size 4097
sprintf(newname, "%s%s", dirname, basename);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
scripts/kconfig/confdata.c:776:23: warning: ‘.tmpconfig.’ directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
sprintf(tmpname, "%s.tmpconfig.%d", dirname, (int)getpid());
^~~~~~~~~~~
scripts/kconfig/confdata.c:776:3: note: ‘sprintf’ output between 13 and 4119 bytes into a destination of size 4097
sprintf(tmpname, "%s.tmpconfig.%d", dirname, (int)getpid());
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Increase the size of tmpname and newname to make GCC happy.
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[sw0312.kim: cherry-pick stable linux-4.9.y commit
1ec1dfba0835 for gcc 9 build]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I7ebafa60f7703732795fe226b1c1eb8c39a27c28
Arnd Bergmann [Thu, 14 Dec 2017 23:32:41 +0000 (15:32 -0800)]
exec: avoid gcc-8 warning for get_task_comm
commit
3756f6401c302617c5e091081ca4d26ab604bec5 upstream.
gcc-8 warns about using strncpy() with the source size as the limit:
fs/exec.c:1223:32: error: argument to 'sizeof' in 'strncpy' call is the same expression as the source; did you mean to use the size of the destination? [-Werror=sizeof-pointer-memaccess]
This is indeed slightly suspicious, as it protects us from source
arguments without NUL-termination, but does not guarantee that the
destination is terminated.
This keeps the strncpy() to ensure we have properly padded target
buffer, but ensures that we use the correct length, by passing the
actual length of the destination buffer as well as adding a build-time
check to ensure it is exactly TASK_COMM_LEN.
There are only 23 callsites which I all reviewed to ensure this is
currently the case. We could get away with doing only the check or
passing the right length, but it doesn't hurt to do both.
Link: http://lkml.kernel.org/r/20171205151724.1764896-1-arnd@arndb.de
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Suggested-by: Kees Cook <keescook@chromium.org>
Acked-by: Kees Cook <keescook@chromium.org>
Acked-by: Ingo Molnar <mingo@kernel.org>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Serge Hallyn <serge@hallyn.com>
Cc: James Morris <james.l.morris@oracle.com>
Cc: Aleksa Sarai <asarai@suse.de>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Frederic Weisbecker <frederic@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[sw0312.kim: cherry-pick stable linux-4.9.y commit
b9dd13488acb for gcc 9 build]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I1d5a998bca751044ef2ac01e569ee500047beb0f
Arnd Bergmann [Thu, 26 Jul 2018 08:13:22 +0000 (10:13 +0200)]
turn off -Wattribute-alias
Starting with gcc-8.1, we get a warning about all system call definitions,
which use an alias between functions with incompatible prototypes, e.g.:
In file included from ../mm/process_vm_access.c:19:
../include/linux/syscalls.h:211:18: warning: 'sys_process_vm_readv' alias between functions of incompatible types 'long int(pid_t, const struct iovec *, long unsigned int, const struct iovec *, long unsigned int, long unsigned int)' {aka 'long int(int, const struct iovec *, long unsigned int, const struct iovec *, long unsigned int, long unsigned int)'} and 'long int(long int, long int, long int, long int, long int, long int)' [-Wattribute-alias]
asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
^~~
../include/linux/syscalls.h:207:2: note: in expansion of macro '__SYSCALL_DEFINEx'
__SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
^~~~~~~~~~~~~~~~~
../include/linux/syscalls.h:201:36: note: in expansion of macro 'SYSCALL_DEFINEx'
#define SYSCALL_DEFINE6(name, ...) SYSCALL_DEFINEx(6, _##name, __VA_ARGS__)
^~~~~~~~~~~~~~~
../mm/process_vm_access.c:300:1: note: in expansion of macro 'SYSCALL_DEFINE6'
SYSCALL_DEFINE6(process_vm_readv, pid_t, pid, const struct iovec __user *, lvec,
^~~~~~~~~~~~~~~
../include/linux/syscalls.h:215:18: note: aliased declaration here
asmlinkage long SyS##name(__MAP(x,__SC_LONG,__VA_ARGS__)) \
^~~
../include/linux/syscalls.h:207:2: note: in expansion of macro '__SYSCALL_DEFINEx'
__SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
^~~~~~~~~~~~~~~~~
../include/linux/syscalls.h:201:36: note: in expansion of macro 'SYSCALL_DEFINEx'
#define SYSCALL_DEFINE6(name, ...) SYSCALL_DEFINEx(6, _##name, __VA_ARGS__)
^~~~~~~~~~~~~~~
../mm/process_vm_access.c:300:1: note: in expansion of macro 'SYSCALL_DEFINE6'
SYSCALL_DEFINE6(process_vm_readv, pid_t, pid, const struct iovec __user *, lvec,
This is really noisy and does not indicate a real problem. In the latest
mainline kernel, this was addressed by commit
bee20031772a ("disable
-Wattribute-alias warning for SYSCALL_DEFINEx()"), which seems too invasive
to backport.
This takes a much simpler approach and just disables the warning across the
kernel.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[sw0312.kim: cherry-pick stable linux-4.9.y commit
b1a1d9bdb1b5 for gcc 9 build]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I930f1ed6c9350d8131e363f2feb0a73bee68007b
Seung-Woo Kim [Mon, 23 Dec 2019 01:21:38 +0000 (10:21 +0900)]
drm/tgm: tdm_pp: msc: check and adjust src/dest size parameter
In msc hw, for both src and dest, image x plus image w should be
equal or less than buffer size vsize and image y plus image shou.d
be equal or less than buffer size hsize. Otherwise, hw tries to
access out of buffer boundary and it causes msc sysmmu page fault.
Fix to check and to adjust src/dest size parameter as the hw
constraint.
Change-Id: Ie6e9d431955e0c369164f2b1f46cf9f17e0b1d8b
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Dongwoo Lee [Fri, 26 Oct 2018 01:41:41 +0000 (10:41 +0900)]
usb: gadget: f_fs: Give chance to retry malloc for large size buffer
The f_fs daemons usually use large size buffer for increasing transfer
performance, but it can cause memory allocation failure in case of
that buddy space is fragmented. Since this, instead of just returning
error in this case, give the chance to retry to allocate memory with
a half length in order to prevent daemon crash due to failure of
buffer allocation.
Change-Id: I2171932b8cb565102d63eb82c114987b85d26ed9
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
Amit Purwar [Mon, 16 Dec 2019 05:58:59 +0000 (11:28 +0530)]
Bluetooth: Enables filter_policy and adv_type set by user
This patch enables the filter_policy and adv_type in advertisement
set by user on MGMT interface using set_advertising_params API.
Currently filter policy and adv_type does not get applied on slot 0
during ADV enable.
Change-Id: I18b2d5bb1db334f2f008b619503582c5eed29f08
Signed-off-by: Amit Purwar <amit.purwar@samsung.com>
Dongwoo Lee [Fri, 22 Nov 2019 06:16:34 +0000 (15:16 +0900)]
arm64: tizen_tw3_defconfig: Use configfs instead of legacy usb gadget
This patch replaces legacy gadget driver with configfs with CDC ACM,
rndis, functionfs support.
Change-Id: I8d96a3e95273ab830b1adf045b641024ed4a50a1
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
Peter Chen [Mon, 26 Aug 2019 19:10:55 +0000 (15:10 -0400)]
usb: gadget: configfs: fix concurrent issue between composite APIs
[ Upstream commit
1a1c851bbd706ea9f3a9756c2d3db28523506d3b ]
We meet several NULL pointer issues if configfs_composite_unbind
and composite_setup (or composite_disconnect) are running together.
These issues occur when do the function switch stress test, the
configfs_compsoite_unbind is called from user mode by
echo "" to /sys/../UDC entry, and meanwhile, the setup interrupt
or disconnect interrupt occurs by hardware. The composite_setup
will get the cdev from get_gadget_data, but configfs_composite_unbind
will set gadget data as NULL, so the NULL pointer issue occurs.
This concurrent is hard to reproduce by native kernel, but can be
reproduced by android kernel.
In this commit, we introduce one spinlock belongs to structure
gadget_info since we can't use the same spinlock in usb_composite_dev
due to exclusive running together between composite_setup and
configfs_composite_unbind. And one bit flag 'unbind' to indicate the
code is at unbind routine, this bit is needed due to we release the
lock at during configfs_composite_unbind sometimes, and composite_setup
may be run at that time.
Several oops:
oops 1:
android_work: sent uevent USB_STATE=CONNECTED
configfs-gadget gadget: super-speed config #1: b
android_work: sent uevent USB_STATE=CONFIGURED
init: Received control message 'start' for 'adbd' from pid: 3515 (system_server)
Unable to handle kernel NULL pointer dereference at virtual address
0000002a
init: Received control message 'stop' for 'adbd' from pid: 3375 (/vendor/bin/hw/android.hardware.usb@1.1-servic)
Mem abort info:
Exception class = DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x00000004
CM = 0, WnR = 0
user pgtable: 4k pages, 48-bit VAs, pgd =
ffff8008f1b7f000
[
000000000000002a] *pgd=
0000000000000000
Internal error: Oops:
96000004 [#1] PREEMPT SMP
Modules linked in:
CPU: 4 PID: 2457 Comm: irq/125-5b11000 Not tainted 4.14.98-07846-g0b40a9b-dirty #16
Hardware name: Freescale i.MX8QM MEK (DT)
task:
ffff8008f2a98000 task.stack:
ffff00000b7b8000
PC is at composite_setup+0x44/0x1508
LR is at android_setup+0xb8/0x13c
pc : [<
ffff0000089ffb3c>] lr : [<
ffff000008a032fc>] pstate:
800001c5
sp :
ffff00000b7bbb80
x29:
ffff00000b7bbb80 x28:
ffff8008f2a3c010
x27:
0000000000000001 x26:
0000000000000000 [1232/1897]
audit: audit_lost=25791 audit_rate_limit=5 audit_backlog_limit=64
x25:
00000000ffffffa1 x24:
ffff8008f2a3c010
audit: rate limit exceeded
x23:
0000000000000409 x22:
ffff000009c8e000
x21:
ffff8008f7a8b428 x20:
ffff00000afae000
x19:
ffff0000089ff000 x18:
0000000000000000
x17:
0000000000000000 x16:
ffff0000082b7c9c
x15:
0000000000000000 x14:
f1866f5b952aca46
x13:
e35502e30d44349c x12:
0000000000000008
x11:
0000000000000008 x10:
0000000000000a30
x9 :
ffff00000b7bbd00 x8 :
ffff8008f2a98a90
x7 :
ffff8008f27a9c90 x6 :
0000000000000001
x5 :
0000000000000000 x4 :
0000000000000001
x3 :
0000000000000000 x2 :
0000000000000006
x1 :
ffff0000089ff8d0 x0 :
732a010310b9ed00
X7: 0xffff8008f27a9c10:
9c10
00000002 00000000 00000001 00000000 13110000 ffff0000 00000002 00208040
9c30
00000000 00000000 00000000 00000000 00000000 00000005 00000029 00000000
9c50
00051778 00000001 f27a8e00 ffff8008 00000005 00000000 00000078 00000078
9c70
00000078 00000000 09031d48 ffff0000 00100000 00000000 00400000 00000000
9c90
00000001 00000000 00000000 00000000 00000000 00000000 ffefb1a0 ffff8008
9cb0
f27a9ca8 ffff8008 00000000 00000000 b9d88037 00000173 1618a3eb 00000001
9cd0
870a792a 0000002e 16188fe6 00000001 0000242b 00000000 00000000 00000000
using random self ethernet address
9cf0
019a4646 00000000 000547f3 00000000 ecfd6c33 00000002 00000000
using random host ethernet address
00000000
X8: 0xffff8008f2a98a10:
8a10
00000000 00000000 f7788d00 ffff8008 00000001 00000000 00000000 00000000
8a30
eb218000 ffff8008 f2a98000 ffff8008 f2a98000 ffff8008 09885000 ffff0000
8a50
f34df480 ffff8008 00000000 00000000 f2a98648 ffff8008 09c8e000 ffff0000
8a70
fff2c800 ffff8008 09031d48 ffff0000 0b7bbd00 ffff0000 0b7bbd00 ffff0000
8a90
080861bc ffff0000 00000000 00000000 00000000 00000000 00000000 00000000
8ab0
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
8ad0
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
8af0
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
X21: 0xffff8008f7a8b3a8:
b3a8
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
b3c8
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
b3e8
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
b408
00000000 00000000 00000000 00000000 00000000 00000000 00000001 00000000
b428
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
b448
0053004d 00540046 00300031 00010030 eb07b520 ffff8008 20011201 00000003
b468
e418d109 0104404e 00010302 00000000 eb07b558 ffff8008 eb07b558 ffff8008
b488
f7a8b488 ffff8008 f7a8b488 ffff8008 f7a8b300 ffff8008 00000000 00000000
X24: 0xffff8008f2a3bf90:
bf90
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bfb0
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bfd0
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bff0
00000000 00000000 00000000 00000000 f76c8010 ffff8008 f76c8010 ffff8008
c010
00000000 00000000 f2a3c018 ffff8008 f2a3c018 ffff8008 08a067dc ffff0000
c030
f2a5a000 ffff8008 091c3650 ffff0000 f716fd18 ffff8008 f716fe30 ffff8008
c050
f2ce4a30 ffff8008 00000000 00000005 00000000 00000000 095d1568 ffff0000
c070
f76c8010 ffff8008 f2ce4b00 ffff8008 095cac68 ffff0000 f2a5a028 ffff8008
X28: 0xffff8008f2a3bf90:
bf90
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bfb0
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bfd0
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bff0
00000000 00000000 00000000 00000000 f76c8010 ffff8008 f76c8010 ffff8008
c010
00000000 00000000 f2a3c018 ffff8008 f2a3c018 ffff8008 08a067dc ffff0000
c030
f2a5a000 ffff8008 091c3650 ffff0000 f716fd18 ffff8008 f716fe30 ffff8008
c050
f2ce4a30 ffff8008 00000000 00000005 00000000 00000000 095d1568 ffff0000
c070
f76c8010 ffff8008 f2ce4b00 ffff8008 095cac68 ffff0000 f2a5a028 ffff8008
Process irq/125-5b11000 (pid: 2457, stack limit = 0xffff00000b7b8000)
Call trace:
Exception stack(0xffff00000b7bba40 to 0xffff00000b7bbb80)
ba40:
732a010310b9ed00 ffff0000089ff8d0 0000000000000006 0000000000000000
ba60:
0000000000000001 0000000000000000 0000000000000001 ffff8008f27a9c90
ba80:
ffff8008f2a98a90 ffff00000b7bbd00 0000000000000a30 0000000000000008
baa0:
0000000000000008 e35502e30d44349c f1866f5b952aca46 0000000000000000
bac0:
ffff0000082b7c9c 0000000000000000 0000000000000000 ffff0000089ff000
bae0:
ffff00000afae000 ffff8008f7a8b428 ffff000009c8e000 0000000000000409
bb00:
ffff8008f2a3c010 00000000ffffffa1 0000000000000000 0000000000000001
bb20:
ffff8008f2a3c010 ffff00000b7bbb80 ffff000008a032fc ffff00000b7bbb80
bb40:
ffff0000089ffb3c 00000000800001c5 ffff00000b7bbb80 732a010310b9ed00
bb60:
ffffffffffffffff ffff0000080f777c ffff00000b7bbb80 ffff0000089ffb3c
[<
ffff0000089ffb3c>] composite_setup+0x44/0x1508
[<
ffff000008a032fc>] android_setup+0xb8/0x13c
[<
ffff0000089bd9a8>] cdns3_ep0_delegate_req+0x44/0x70
[<
ffff0000089bdff4>] cdns3_check_ep0_interrupt_proceed+0x33c/0x654
[<
ffff0000089bca44>] cdns3_device_thread_irq_handler+0x4b0/0x4bc
[<
ffff0000089b77b4>] cdns3_thread_irq+0x48/0x68
[<
ffff000008145bf0>] irq_thread_fn+0x28/0x88
[<
ffff000008145e38>] irq_thread+0x13c/0x228
[<
ffff0000080fed70>] kthread+0x104/0x130
[<
ffff000008085064>] ret_from_fork+0x10/0x18
oops2:
composite_disconnect: Calling disconnect on a Gadget that is not connected
android_work: did not send uevent (0 0 (null))
init: Received control message 'stop' for 'adbd' from pid: 3359 (/vendor/bin/hw/android.hardware.usb@1.1-service.imx)
init: Sending signal 9 to service 'adbd' (pid 22343) process group...
------------[ cut here ]------------
audit: audit_lost=180038 audit_rate_limit=5 audit_backlog_limit=64
audit: rate limit exceeded
WARNING: CPU: 0 PID: 3468 at kernel_imx/drivers/usb/gadget/composite.c:2009 composite_disconnect+0x80/0x88
Modules linked in:
CPU: 0 PID: 3468 Comm: HWC-UEvent-Thre Not tainted 4.14.98-07846-g0b40a9b-dirty #16
Hardware name: Freescale i.MX8QM MEK (DT)
task:
ffff8008f2349c00 task.stack:
ffff00000b0a8000
PC is at composite_disconnect+0x80/0x88
LR is at composite_disconnect+0x80/0x88
pc : [<
ffff0000089ff9b0>] lr : [<
ffff0000089ff9b0>] pstate:
600001c5
sp :
ffff000008003dd0
x29:
ffff000008003dd0 x28:
ffff8008f2349c00
x27:
ffff000009885018 x26:
ffff000008004000
Timeout for IPC response!
x25:
ffff000009885018 x24:
ffff000009c8e280
x23:
ffff8008f2d98010 x22:
00000000000001c0
x21:
ffff8008f2d98394 x20:
ffff8008f2d98010
x19:
0000000000000000 x18:
0000e3956f4f075a
fxos8700 4-001e: i2c block read acc failed
x17:
0000e395735727e8 x16:
ffff00000829f4d4
x15:
ffffffffffffffff x14:
7463656e6e6f6320
x13:
746f6e2009090920 x12:
7369207461687420
x11:
7465676461472061 x10:
206e6f207463656e
x9 :
6e6f637369642067 x8 :
ffff000009c8e280
x7 :
ffff0000086ca6cc x6 :
ffff000009f15e78
x5 :
0000000000000000 x4 :
0000000000000000
x3 :
ffffffffffffffff x2 :
c3f28b86000c3900
x1 :
c3f28b86000c3900 x0 :
000000000000004e
X20: 0xffff8008f2d97f90:
7f90
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
7fb0
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
libprocessgroup: Failed to kill process cgroup uid 0 pid 22343 in 215ms, 1 processes remain
7fd0
Timeout for IPC response!
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
using random self ethernet address
7ff0
00000000 00000000 00000000 00000000 f76c8010 ffff8008 f76c8010 ffff8008
8010
00000100 00000000 f2d98018 ffff8008 f2d98018 ffff8008 08a067dc
using random host ethernet address
ffff0000
8030
f206d800 ffff8008 091c3650 ffff0000 f7957b18 ffff8008 f7957730 ffff8008
8050
f716a630 ffff8008 00000000 00000005 00000000 00000000 095d1568 ffff0000
8070
f76c8010 ffff8008 f716a800 ffff8008 095cac68 ffff0000 f206d828 ffff8008
X21: 0xffff8008f2d98314:
8314
ffff8008 00000000 00000000 00000000 00000000 00000000 00000000 00000000
8334
00000000 00000000 00000000 00000000 00000000 08a04cf4 ffff0000 00000000
8354
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
8374
00000000 00000000 00000000 00001001 00000000 00000000 00000000 00000000
8394
e4bbe4bb 0f230000 ffff0000 0afae000 ffff0000 ae001000 00000000 f206d400
Timeout for IPC response!
83b4
ffff8008 00000000 00000000 f7957b18 ffff8008 f7957718 ffff8008 f7957018
83d4
ffff8008 f7957118 ffff8008 f7957618 ffff8008 f7957818 ffff8008 f7957918
83f4
ffff8008 f7957d18 ffff8008 00000000 00000000 00000000 00000000 00000000
X23: 0xffff8008f2d97f90:
7f90
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
7fb0
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
7fd0
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
7ff0
00000000 00000000 00000000 00000000 f76c8010 ffff8008 f76c8010 ffff8008
8010
00000100 00000000 f2d98018 ffff8008 f2d98018 ffff8008 08a067dc ffff0000
8030
f206d800 ffff8008 091c3650 ffff0000 f7957b18 ffff8008 f7957730 ffff8008
8050
f716a630 ffff8008 00000000 00000005 00000000 00000000 095d1568 ffff0000
8070
f76c8010 ffff8008 f716a800 ffff8008 095cac68 ffff0000 f206d828 ffff8008
X28: 0xffff8008f2349b80:
9b80
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
9ba0
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
9bc0
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
9be0
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
9c00
00000022 00000000 ffffffff ffffffff 00010001 00000000 00000000 00000000
9c20
0b0a8000 ffff0000 00000002 00404040 00000000 00000000 00000000 00000000
9c40
00000001 00000000 00000001 00000000 001ebd44 00000001 f390b800 ffff8008
9c60
00000000 00000001 00000070 00000070 00000070 00000000 09031d48 ffff0000
Call trace:
Exception stack(0xffff000008003c90 to 0xffff000008003dd0)
3c80:
000000000000004e c3f28b86000c3900
3ca0:
c3f28b86000c3900 ffffffffffffffff 0000000000000000 0000000000000000
3cc0:
ffff000009f15e78 ffff0000086ca6cc ffff000009c8e280 6e6f637369642067
3ce0:
206e6f207463656e 7465676461472061 7369207461687420 746f6e2009090920
3d00:
7463656e6e6f6320 ffffffffffffffff ffff00000829f4d4 0000e395735727e8
3d20:
0000e3956f4f075a 0000000000000000 ffff8008f2d98010 ffff8008f2d98394
3d40:
00000000000001c0 ffff8008f2d98010 ffff000009c8e280 ffff000009885018
3d60:
ffff000008004000 ffff000009885018 ffff8008f2349c00 ffff000008003dd0
3d80:
ffff0000089ff9b0 ffff000008003dd0 ffff0000089ff9b0 00000000600001c5
3da0:
ffff8008f33f2cd8 0000000000000000 0000ffffffffffff 0000000000000000
init: Received control message 'start' for 'adbd' from pid: 3359 (/vendor/bin/hw/android.hardware.usb@1.1-service.imx)
3dc0:
ffff000008003dd0 ffff0000089ff9b0
[<
ffff0000089ff9b0>] composite_disconnect+0x80/0x88
[<
ffff000008a044d4>] android_disconnect+0x3c/0x68
[<
ffff0000089ba9f8>] cdns3_device_irq_handler+0xfc/0x2c8
[<
ffff0000089b84c0>] cdns3_irq+0x44/0x94
[<
ffff00000814494c>] __handle_irq_event_percpu+0x60/0x24c
[<
ffff000008144c0c>] handle_irq_event+0x58/0xc0
[<
ffff00000814873c>] handle_fasteoi_irq+0x98/0x180
[<
ffff000008143a10>] generic_handle_irq+0x24/0x38
[<
ffff000008144170>] __handle_domain_irq+0x60/0xac
[<
ffff0000080819c4>] gic_handle_irq+0xd4/0x17c
Signed-off-by: Peter Chen <peter.chen@nxp.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[dwoo08.lee: cherry-pick linux-4.9.y stable commit
59682e70c980 and resolve conflicts to stablize configfs]
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
Change-Id: I891e07b46cb1783e5f1c7a1c5a6198bb62611b20
John Keeping [Tue, 28 Feb 2017 10:55:30 +0000 (10:55 +0000)]
usb: gadget: configs: plug memory leak
[ Upstream commit
38355b2a44776c25b0f2ad466e8c51bb805b3032 ]
When binding a gadget to a device, "name" is stored in gi->udc_name, but
this does not happen when unregistering and the string is leaked.
Signed-off-by: John Keeping <john@metanate.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[dwoo08.lee: cherry-pick linux-4.9.y stable commit
59682e70c980 to stablize configfs]
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
Change-Id: Ieb2bcfeed245a0b993ac6c4992af8fe27fc89d48
Andrzej Pietrasiewicz [Mon, 3 Jun 2019 17:05:28 +0000 (19:05 +0200)]
usb: gadget: Zero ffs_io_data
[ Upstream commit
508595515f4bcfe36246e4a565cf280937aeaade ]
In some cases the "Allocate & copy" block in ffs_epfile_io() is not
executed. Consequently, in such a case ffs_alloc_buffer() is never called
and struct ffs_io_data is not initialized properly. This in turn leads to
problems when ffs_free_buffer() is called at the end of ffs_epfile_io().
This patch uses kzalloc() instead of kmalloc() in the aio case and memset()
in non-aio case to properly initialize struct ffs_io_data.
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[dwoo08.lee: cherry-pick linux-4.9.y stable commit
d585589e5f9b to stablize f_fs]
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
Change-Id: I33ef7d5123301beb94b9d8530664d861464f4bb1
John Stultz [Tue, 5 Feb 2019 18:24:40 +0000 (10:24 -0800)]
usb: f_fs: Avoid crash due to out-of-scope stack ptr access
[ Upstream commit
54f64d5c983f939901dacc8cfc0983727c5c742e ]
Since the 5.0 merge window opened, I've been seeing frequent
crashes on suspend and reboot with the trace:
[ 36.911170] Unable to handle kernel paging request at virtual address
ffffff801153d660
[ 36.912769] Unable to handle kernel paging request at virtual address
ffffff800004b564
...
[ 36.950666] Call trace:
[ 36.950670] queued_spin_lock_slowpath+0x1cc/0x2c8
[ 36.950681] _raw_spin_lock_irqsave+0x64/0x78
[ 36.950692] complete+0x28/0x70
[ 36.950703] ffs_epfile_io_complete+0x3c/0x50
[ 36.950713] usb_gadget_giveback_request+0x34/0x108
[ 36.950721] dwc3_gadget_giveback+0x50/0x68
[ 36.950723] dwc3_thread_interrupt+0x358/0x1488
[ 36.950731] irq_thread_fn+0x30/0x88
[ 36.950734] irq_thread+0x114/0x1b0
[ 36.950739] kthread+0x104/0x130
[ 36.950747] ret_from_fork+0x10/0x1c
I isolated this down to in ffs_epfile_io():
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/gadget/function/f_fs.c#n1065
Where the completion done is setup on the stack:
DECLARE_COMPLETION_ONSTACK(done);
Then later we setup a request and queue it, and wait for it:
if (unlikely(wait_for_completion_interruptible(&done))) {
/*
* To avoid race condition with ffs_epfile_io_complete,
* dequeue the request first then check
* status. usb_ep_dequeue API should guarantee no race
* condition with req->complete callback.
*/
usb_ep_dequeue(ep->ep, req);
interrupted = ep->status < 0;
}
The problem is, that we end up being interrupted, dequeue the
request, and exit.
But then the irq triggers and we try calling complete() on the
context pointer which points to now random stack space, which
results in the panic.
Alan Stern pointed out there is a bug here, in that the snippet
above "assumes that usb_ep_dequeue() waits until the request has
been completed." And that:
wait_for_completion(&done);
Is needed right after the usb_ep_dequeue().
Thus this patch implements that change. With it I no longer see
the crashes on suspend or reboot.
This issue seems to have been uncovered by behavioral changes in
the dwc3 driver in commit
fec9095bdef4e ("usb: dwc3: gadget:
remove wait_end_transfer").
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Felipe Balbi <balbi@kernel.org>
Cc: Zeng Tao <prime.zeng@hisilicon.com>
Cc: Jack Pham <jackp@codeaurora.org>
Cc: Thinh Nguyen <thinh.nguyen@synopsys.com>
Cc: Chen Yu <chenyu56@huawei.com>
Cc: Jerry Zhang <zhangjerry@google.com>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Vincent Pelletier <plr.vincent@gmail.com>
Cc: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Linux USB List <linux-usb@vger.kernel.org>
Suggested-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[dwoo08.lee: cherry-pick linux-4.9.y stable commit
49145924e804 to stablize f_fs]
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
Change-Id: I5a786991ea9ceef96ff6c6b65dc807f842356fd6
Jerry Zhang [Mon, 2 Jul 2018 19:48:08 +0000 (12:48 -0700)]
usb: gadget: f_fs: Only return delayed status when len is 0
commit
4d644abf25698362bd33d17c9ddc8f7122c30f17 upstream.
Commit
1b9ba000 ("Allow function drivers to pause control
transfers") states that USB_GADGET_DELAYED_STATUS is only
supported if data phase is 0 bytes.
It seems that when the length is not 0 bytes, there is no
need to explicitly delay the data stage since the transfer
is not completed until the user responds. However, when the
length is 0, there is no data stage and the transfer is
finished once setup() returns, hence there is a need to
explicitly delay completion.
This manifests as the following bugs:
Prior to
946ef68ad4e4 ('Let setup() return
USB_GADGET_DELAYED_STATUS'), when setup is 0 bytes, ffs
would require user to queue a 0 byte request in order to
clear setup state. However, that 0 byte request was actually
not needed and would hang and cause errors in other setup
requests.
After the above commit, 0 byte setups work since the gadget
now accepts empty queues to ep0 to clear the delay, but all
other setups hang.
Fixes:
946ef68ad4e4 ("Let setup() return USB_GADGET_DELAYED_STATUS")
Signed-off-by: Jerry Zhang <zhangjerry@google.com>
Cc: stable <stable@vger.kernel.org>
Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[dwoo08.lee: cherry-pick linux-4.9.y stable commit
9e10043b6bdc to stablize f_fs]
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
Change-Id: Idf5d504bd5059cc5141f4a3e98c572708c631079
Lars-Peter Clausen [Fri, 12 Jan 2018 10:05:02 +0000 (11:05 +0100)]
usb: gadget: ffs: Execute copy_to_user() with USER_DS set
[ Upstream commit
4058ebf33cb0be88ca516f968eda24ab7b6b93e4 ]
When using a AIO read() operation on the function FS gadget driver a URB is
submitted asynchronously and on URB completion the received data is copied
to the userspace buffer associated with the read operation.
This is done from a kernel worker thread invoking copy_to_user() (through
copy_to_iter()). And while the user space process memory is made available
to the kernel thread using use_mm(), some architecture require in addition
to this that the operation runs with USER_DS set. Otherwise the userspace
memory access will fail.
For example on ARM64 with Privileged Access Never (PAN) and User Access
Override (UAO) enabled the following crash occurs.
Internal error: Accessing user space memory with fs=KERNEL_DS:
9600004f [#1] SMP
Modules linked in:
CPU: 2 PID: 1636 Comm: kworker/2:1 Not tainted 4.9.0-04081-g8ab2dfb-dirty #487
Hardware name: ZynqMP ZCU102 Rev1.0 (DT)
Workqueue: events ffs_user_copy_worker
task:
ffffffc87afc8080 task.stack:
ffffffc87a00c000
PC is at __arch_copy_to_user+0x190/0x220
LR is at copy_to_iter+0x78/0x3c8
[...]
[<
ffffff800847b790>] __arch_copy_to_user+0x190/0x220
[<
ffffff80086f25d8>] ffs_user_copy_worker+0x70/0x130
[<
ffffff80080b8c64>] process_one_work+0x1dc/0x460
[<
ffffff80080b8f38>] worker_thread+0x50/0x4b0
[<
ffffff80080bf5a0>] kthread+0xd8/0xf0
[<
ffffff8008083680>] ret_from_fork+0x10/0x50
Address this by placing a set_fs(USER_DS) before of the copy operation
and revert it again once the copy operation has finished.
This patch is analogous to commit
d7ffde35e31a ("vhost: use USER_DS in
vhost_worker thread") which addresses the same underlying issue.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[dwoo08.lee: cherry-pick linux-4.9.y stable commit
5209c778346a to stablize f_fs]
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
Change-Id: Iee47b31c16c2f83540e4e1f8bd3f3eaebd727ad2
Lars-Peter Clausen [Fri, 12 Jan 2018 10:26:16 +0000 (11:26 +0100)]
usb: gadget: ffs: Let setup() return USB_GADGET_DELAYED_STATUS
[ Upstream commit
946ef68ad4e45aa048a5fb41ce8823ed29da866a ]
Some UDC drivers (like the DWC3) expect that the response to a setup()
request is queued from within the setup function itself so that it is
available as soon as setup() has completed.
Upon receiving a setup request the function fs driver creates an event that
is made available to userspace. And only once userspace has acknowledged
that event the response to the setup request is queued.
So it violates the requirement of those UDC drivers and random failures can
be observed. This is basically a race condition and if userspace is able to
read the event and queue the response fast enough all is good. But if it is
not, for example because other processes are currently scheduled to run,
the USB host that sent the setup request will observe an error.
To avoid this the gadget framework provides the USB_GADGET_DELAYED_STATUS
return code. If a setup() callback returns this value the UDC driver is
aware that response is not yet available and can uses the appropriate
methods to handle this case.
Since in the case of function fs the response will never be available when
the setup() function returns make sure that this status code is used.
This fixed random occasional failures that were previously observed on a
DWC3 based system under high system load.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[dwoo08.lee: cherry-pick linux-4.9.y stable commit
10be2659c629 to stablize f_fs]
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
Change-Id: I1b88c4739c9007bfd515b670401035ef2bc541fc
Xinyong [Fri, 2 Mar 2018 11:20:07 +0000 (19:20 +0800)]
usb: gadget: f_fs: Fix use-after-free in ffs_fs_kill_sb()
commit
1a087f032111a88e826877449dfb93ceb22b78b9 upstream.
When I debug a kernel crash issue in funcitonfs, found ffs_data.ref
overflowed, While functionfs is unmounting, ffs_data is put twice.
Commit
43938613c6fd ("drivers, usb: convert ffs_data.ref from atomic_t to
refcount_t") can avoid refcount overflow, but that is risk some situations.
So no need put ffs data in ffs_fs_kill_sb, already put in ffs_data_closed.
The issue can be reproduced in Mediatek mt6763 SoC, ffs for ADB device.
KASAN enabled configuration reports use-after-free errro.
BUG: KASAN: use-after-free in refcount_dec_and_test+0x14/0xe0 at addr
ffffffc0579386a0
Read of size 4 by task umount/4650
====================================================
BUG kmalloc-512 (Tainted: P W O ): kasan: bad access detected
-----------------------------------------------------------------------------
INFO: Allocated in ffs_fs_mount+0x194/0x844 age=22856 cpu=2 pid=566
alloc_debug_processing+0x1ac/0x1e8
___slab_alloc.constprop.63+0x640/0x648
__slab_alloc.isra.57.constprop.62+0x24/0x34
kmem_cache_alloc_trace+0x1a8/0x2bc
ffs_fs_mount+0x194/0x844
mount_fs+0x6c/0x1d0
vfs_kern_mount+0x50/0x1b4
do_mount+0x258/0x1034
INFO: Freed in ffs_data_put+0x25c/0x320 age=0 cpu=3 pid=4650
free_debug_processing+0x22c/0x434
__slab_free+0x2d8/0x3a0
kfree+0x254/0x264
ffs_data_put+0x25c/0x320
ffs_data_closed+0x124/0x15c
ffs_fs_kill_sb+0xb8/0x110
deactivate_locked_super+0x6c/0x98
deactivate_super+0xb0/0xbc
INFO: Object 0xffffffc057938600 @offset=1536 fp=0x (null)
......
Call trace:
[<
ffffff900808cf5c>] dump_backtrace+0x0/0x250
[<
ffffff900808d3a0>] show_stack+0x14/0x1c
[<
ffffff90084a8c04>] dump_stack+0xa0/0xc8
[<
ffffff900826c2b4>] print_trailer+0x158/0x260
[<
ffffff900826d9d8>] object_err+0x3c/0x40
[<
ffffff90082745f0>] kasan_report_error+0x2a8/0x754
[<
ffffff9008274f84>] kasan_report+0x5c/0x60
[<
ffffff9008273208>] __asan_load4+0x70/0x88
[<
ffffff90084cd81c>] refcount_dec_and_test+0x14/0xe0
[<
ffffff9008d98f9c>] ffs_data_put+0x80/0x320
[<
ffffff9008d9d904>] ffs_fs_kill_sb+0xc8/0x110
[<
ffffff90082852a0>] deactivate_locked_super+0x6c/0x98
[<
ffffff900828537c>] deactivate_super+0xb0/0xbc
[<
ffffff90082af0c0>] cleanup_mnt+0x64/0xec
[<
ffffff90082af1b0>] __cleanup_mnt+0x10/0x18
[<
ffffff90080d9e68>] task_work_run+0xcc/0x124
[<
ffffff900808c8c0>] do_notify_resume+0x60/0x70
[<
ffffff90080866e4>] work_pending+0x10/0x14
Cc: stable@vger.kernel.org
Signed-off-by: Xinyong <xinyong.fang@linux.alibaba.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[dwoo08.lee: cherry-pick linux-4.9.y stable commit
dddf4650cf64 to stablize f_fs]
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
Change-Id: I32845cb6181c82662c8873505c2d9aff3f3f980c
Jack Pham [Wed, 24 Jan 2018 08:11:53 +0000 (00:11 -0800)]
usb: gadget: f_fs: Process all descriptors during bind
commit
6cf439e0d37463e42784271179c8a308fd7493c6 upstream.
During _ffs_func_bind(), the received descriptors are evaluated
to prepare for binding with the gadget in order to allocate
endpoints and optionally set up OS descriptors. However, the
high- and super-speed descriptors are only parsed based on
whether the gadget_is_dualspeed() and gadget_is_superspeed()
calls are true, respectively.
This is a problem in case a userspace program always provides
all of the {full,high,super,OS} descriptors when configuring a
function. Then, for example if a gadget device is not capable
of SuperSpeed, the call to ffs_do_descs() for the SS descriptors
is skipped, resulting in an incorrect offset calculation for
the vla_ptr when moving on to the OS descriptors that follow.
This causes ffs_do_os_descs() to fail as it is now looking at
the SS descriptors' offset within the raw_descs buffer instead.
_ffs_func_bind() should evaluate the descriptors unconditionally,
so remove the checks for gadget speed.
Fixes:
f0175ab51993 ("usb: gadget: f_fs: OS descriptors support")
Cc: stable@vger.kernel.org
Co-Developed-by: Mayank Rana <mrana@codeaurora.org>
Signed-off-by: Mayank Rana <mrana@codeaurora.org>
Signed-off-by: Jack Pham <jackp@codeaurora.org>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[dwoo08.lee: cherry-pick linux-4.9.y stable commit
8bedacf13d59 to stablize f_fs]
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
Change-Id: I0ed8330a0e692ea80263f31b7804203edfbd2d4d
Hemant Kumar [Tue, 9 Jan 2018 07:00:53 +0000 (12:30 +0530)]
usb: f_fs: Prevent gadget unbind if it is already unbound
commit
ce5bf9a50daf2d9078b505aca1cea22e88ecb94a upstream.
Upon usb composition switch there is possibility of ep0 file
release happening after gadget driver bind. In case of composition
switch from adb to a non-adb composition gadget will never gets
bound again resulting into failure of usb device enumeration. Fix
this issue by checking FFS_FL_BOUND flag and avoid extra
gadget driver unbind if it is already done as part of composition
switch.
This fixes adb reconnection error reported on Android running
v4.4 and above kernel versions. Verified on Hikey running vanilla
v4.15-rc7 + few out of tree Mali patches.
Reviewed-at: https://android-review.googlesource.com/#/c/582632/
Cc: Felipe Balbi <balbi@kernel.org>
Cc: Greg KH <gregkh@linux-foundation.org>
Cc: Michal Nazarewicz <mina86@mina86.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Dmitry Shmidt <dimitrysh@google.com>
Cc: Badhri <badhri@google.com>
Cc: Android Kernel Team <kernel-team@android.com>
Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>
[AmitP: Cherry-picked it from android-4.14 and updated the commit log]
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[dwoo08.lee: cherry-pick linux-4.9.y stable commit
f24d171a8100 to stablize f_fs]
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
Change-Id: Ifbab9f182fa3779c57ab288958553c3711d50e28
Vincent Pelletier [Sun, 26 Nov 2017 06:52:53 +0000 (06:52 +0000)]
usb: gadget: ffs: Forbid usb_ep_alloc_request from sleeping
commit
30bf90ccdec1da9c8198b161ecbff39ce4e5a9ba upstream.
Found using DEBUG_ATOMIC_SLEEP while submitting an AIO read operation:
[ 100.853642] BUG: sleeping function called from invalid context at mm/slab.h:421
[ 100.861148] in_atomic(): 1, irqs_disabled(): 1, pid: 1880, name: python
[ 100.867954] 2 locks held by python/1880:
[ 100.867961] #0: (&epfile->mutex){....}, at: [<
f8188627>] ffs_mutex_lock+0x27/0x30 [usb_f_fs]
[ 100.868020] #1: (&(&ffs->eps_lock)->rlock){....}, at: [<
f818ad4b>] ffs_epfile_io.isra.17+0x24b/0x590 [usb_f_fs]
[ 100.868076] CPU: 1 PID: 1880 Comm: python Not tainted 4.14.0-edison+ #118
[ 100.868085] Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542 2015.01.21:18.19.48
[ 100.868093] Call Trace:
[ 100.868122] dump_stack+0x47/0x62
[ 100.868156] ___might_sleep+0xfd/0x110
[ 100.868182] __might_sleep+0x68/0x70
[ 100.868217] kmem_cache_alloc_trace+0x4b/0x200
[ 100.868248] ? dwc3_gadget_ep_alloc_request+0x24/0xe0 [dwc3]
[ 100.868302] dwc3_gadget_ep_alloc_request+0x24/0xe0 [dwc3]
[ 100.868343] usb_ep_alloc_request+0x16/0xc0 [udc_core]
[ 100.868386] ffs_epfile_io.isra.17+0x444/0x590 [usb_f_fs]
[ 100.868424] ? _raw_spin_unlock_irqrestore+0x27/0x40
[ 100.868457] ? kiocb_set_cancel_fn+0x57/0x60
[ 100.868477] ? ffs_ep0_poll+0xc0/0xc0 [usb_f_fs]
[ 100.868512] ffs_epfile_read_iter+0xfe/0x157 [usb_f_fs]
[ 100.868551] ? security_file_permission+0x9c/0xd0
[ 100.868587] ? rw_verify_area+0xac/0x120
[ 100.868633] aio_read+0x9d/0x100
[ 100.868692] ? __fget+0xa2/0xd0
[ 100.868727] ? __might_sleep+0x68/0x70
[ 100.868763] SyS_io_submit+0x471/0x680
[ 100.868878] do_int80_syscall_32+0x4e/0xd0
[ 100.868921] entry_INT80_32+0x2a/0x2a
[ 100.868932] EIP: 0xb7fbb676
[ 100.868941] EFLAGS:
00000292 CPU: 1
[ 100.868951] EAX:
ffffffda EBX:
b7aa2000 ECX:
00000002 EDX:
b7af8368
[ 100.868961] ESI:
b7fbb660 EDI:
b7aab000 EBP:
bfb6c658 ESP:
bfb6c638
[ 100.868973] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b
Signed-off-by: Vincent Pelletier <plr.vincent@gmail.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[dwoo08.lee: cherry-pick linux-4.9.y stable commit
16648cbcd332 to stablize f_fs]
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
Change-Id: I7716588e2a674be3f5f602273fd283273b87b730
John Keeping [Mon, 27 Nov 2017 18:15:40 +0000 (18:15 +0000)]
usb: f_fs: Force Reserved1=1 in OS_DESC_EXT_COMPAT
commit
a3acc696085e112733d191a77b106e67a4fa110b upstream.
The specification says that the Reserved1 field in OS_DESC_EXT_COMPAT
must have the value "1", but when this feature was first implemented we
rejected any non-zero values.
This was adjusted to accept all non-zero values (while now rejecting
zero) in commit
53642399aa71 ("usb: gadget: f_fs: Fix wrong check on
reserved1 of OS_DESC_EXT_COMPAT"), but that breaks any userspace
programs that worked previously by returning EINVAL when Reserved1 == 0
which was previously the only value that succeeded!
If we just set the field to "1" ourselves, both old and new userspace
programs continue to work correctly and, as a bonus, old programs are
now compliant with the specification without having to fix anything
themselves.
Fixes:
53642399aa71 ("usb: gadget: f_fs: Fix wrong check on reserved1 of OS_DESC_EXT_COMPAT")
Signed-off-by: John Keeping <john@metanate.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[dwoo08.lee: cherry-pick linux-4.9.y stable commit
112b8a8f558d to stablize f_fs]
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
Change-Id: I00f7fce7bc2c5225c3f9ec00f30d1e4f4f0582de
Vincent Pelletier [Thu, 15 Dec 2016 12:47:42 +0000 (12:47 +0000)]
usb: gadget: f_fs: Fix ExtCompat descriptor validation
[ Upstream commit
354bc45bf329494ef6051f3229ef50b9e2a7ea2a ]
Reserved1 is documented as expected to be set to 0, but this test fails
when it it set to 0. Reverse the condition.
Signed-off-by: Vincent Pelletier <plr.vincent@gmail.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[dwoo08.lee: cherry-pick linux-4.9.y stable commit
5eb97be87981 to stablize f_fs]
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
Change-Id: Id8bd89a9cb5343fd0830d480ad5b2900367d8056
Andrew Gabbasov [Wed, 8 Nov 2017 17:13:15 +0000 (10:13 -0700)]
usb: gadget: f_fs: Fix use-after-free in ffs_free_inst
commit
cdafb6d8b8da7fde266f79b3287ac221aa841879 upstream.
KASAN enabled configuration reports an error
BUG: KASAN: use-after-free in ffs_free_inst+... [usb_f_fs] at addr ...
Write of size 8 by task ...
This is observed after "ffs-test" is run and interrupted. If after that
functionfs is unmounted and g_ffs module is unloaded, that use-after-free
occurs during g_ffs module removal.
Although the report indicates ffs_free_inst() function, the actual
use-after-free condition occurs in _ffs_free_dev() function, which
is probably inlined into ffs_free_inst().
This happens due to keeping the ffs_data reference in device structure
during functionfs unmounting, while ffs_data itself is freed as no longer
needed. The fix is to clear that reference in ffs_closed() function,
which is a counterpart of ffs_ready(), where the reference is stored.
Fixes:
3262ad824307 ("usb: gadget: f_fs: Stop ffs_closed NULL pointer dereference")
Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com>
Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[dwoo08.lee: cherry-pick linux-4.9.y stable commit
fd6a742d8bf7 to stablize f_fs]
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
Change-Id: I6e32305fee754d8a11eaa0650319e8e620d4c2af
Seung-Woo Kim [Tue, 19 Nov 2019 01:21:01 +0000 (10:21 +0900)]
[LOCAL] arm64/ptrace: Add compat FPR register support
From aarch32 ptrace view, fpr register support is done with vfp
registers. As like aarch32 ptrace view, Add to suppot compat fpr
resister with vfp.
Change-Id: If5b4b6b5f33b7691ba9d3b65c1bffcf316e19588
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Seung-Woo Kim [Wed, 11 Dec 2019 00:57:56 +0000 (09:57 +0900)]
[LOCAL] arm64: perf: Report arm pc registers for compat perf
If perf is built as arm 32-bit, it only reads 15 registers as arm
32-bit register map and this breaks dwarf call-chain in compat
perf because pc register information is not filled.
Report arm pc registers for 32-bit compat perf.
Without this, arm 32-bit perf dwarf call-graph shows below
verbose message:
unwind: reg 15, val 0
unwind: reg 13, val
ffbc6360
unwind: no map for 0
Posted to mainline[1] but never merged.
[1]: https://patchwork.kernel.org/patch/
11238463/
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I8c35067224707b3077d7bfd14efda7c20c8d2869
Mark Rutland [Thu, 15 Nov 2018 22:42:01 +0000 (22:42 +0000)]
arm64: ftrace: don't adjust the LR value
[ Upstream commit
6e803e2e6e367db9a0d6ecae1bd24bb5752011bd ]
The core ftrace code requires that when it is handed the PC of an
instrumented function, this PC is the address of the instrumented
instruction. This is necessary so that the core ftrace code can identify
the specific instrumentation site. Since the instrumented function will
be a BL, the address of the instrumented function is LR - 4 at entry to
the ftrace code.
This fixup is applied in the mcount_get_pc and mcount_get_pc0 helpers,
which acquire the PC of the instrumented function.
The mcount_get_lr helper is used to acquire the LR of the instrumented
function, whose value does not require this adjustment, and cannot be
adjusted to anything meaningful. No adjustment of this value is made on
other architectures, including arm. However, arm64 adjusts this value by
4.
This patch brings arm64 in line with other architectures and removes the
adjustment of the LR value.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Torsten Duwe <duwe@suse.de>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[sw0312.kim: cherry-pick linux-4.9.y stable commit
bfadca610fcf to fix ftrace issue]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: Ib9a2bd4728efeb0b1fa28e60135ba596bac55ace
Julien Thierry [Fri, 3 Nov 2017 11:44:16 +0000 (11:44 +0000)]
arm64: Fix static use of function graph
Function graph does not work currently when CONFIG_DYNAMIC_TRACE is not
set. This is because ftrace_function_trace is not always set to ftrace_stub
when function_graph is in use.
Do not skip checking of graph tracer functions when ftrace_function_trace
is set.
Signed-off-by: Julien Thierry <julien.thierry@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Reviewed-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
[sw0312.kim: cherry-pick mainline commit
d125bffcefb2 to fix function_graph without CONFIG_DYNAMIC_TRACE]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I7eddd61e45ed2f459bd70785126eaf551ee7a3d2