review.tizen.org Git - profile/mobile/platform/kernel/linux-3.10-sc7730.git/log

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: backport upstream commit 8e8ab8554aa4 to resolve gcc-12 build issue]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I05bbd91ea85995f1539bd1fb9b3a0cfe812fdb13

capabilities: add a securebit to disable PR_CAP_AMBIENT_RAISE

Per Andrew Morgan's request, add a securebit to allow admins to disable
PR_CAP_AMBIENT_RAISE. This securebit will prevent processes from adding
capabilities to their ambient set.

For simplicity, this disables PR_CAP_AMBIENT_RAISE entirely rather than
just disabling setting previously cleared bits.

Change-Id: I0a81bd7a3ede292e3e966633d3a2181fc9166078
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Acked-by: Andrew G. Morgan <morgan@kernel.org>
Acked-by: Serge Hallyn <serge.hallyn@canonical.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Christoph Lameter <cl@linux.com>
Cc: Serge Hallyn <serge.hallyn@canonical.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Aaron Jones <aaronmdjones@gmail.com>
Cc: Ted Ts'o <tytso@mit.edu>
Cc: Andrew G. Morgan <morgan@kernel.org>
Cc: Mimi Zohar <zohar@linux.vnet.ibm.com>
Cc: Austin S Hemmelgarn <ahferroin7@gmail.com>
Cc: Markku Savela <msa@moth.iki.fi>
Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>
Cc: James Morris <james.l.morris@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Origin: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=746bf6d64275be0c65b0631d8a72b16f1454cfa1
Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>

capabilities: ambient capabilities

Credit where credit is due: this idea comes from Christoph Lameter with
a lot of valuable input from Serge Hallyn.  This patch is heavily based
on Christoph's patch.

===== The status quo =====

On Linux, there are a number of capabilities defined by the kernel.  To
perform various privileged tasks, processes can wield capabilities that
they hold.

Each task has four capability masks: effective (pE), permitted (pP),
inheritable (pI), and a bounding set (X).  When the kernel checks for a
capability, it checks pE.  The other capability masks serve to modify
what capabilities can be in pE.

Any task can remove capabilities from pE, pP, or pI at any time.  If a
task has a capability in pP, it can add that capability to pE and/or pI.
If a task has CAP_SETPCAP, then it can add any capability to pI, and it
can remove capabilities from X.

Tasks are not the only things that can have capabilities; files can also
have capabilities.  A file can have no capabilty information at all [1].
If a file has capability information, then it has a permitted mask (fP)
and an inheritable mask (fI) as well as a single effective bit (fE) [2].
File capabilities modify the capabilities of tasks that execve(2) them.

A task that successfully calls execve has its capabilities modified for
the file ultimately being excecuted (i.e.  the binary itself if that
binary is ELF or for the interpreter if the binary is a script.) [3] In
the capability evolution rules, for each mask Z, pZ represents the old
value and pZ' represents the new value.  The rules are:

  pP' = (X & fP) | (pI & fI)
  pI' = pI
  pE' = (fE ? pP' : 0)
  X is unchanged

For setuid binaries, fP, fI, and fE are modified by a moderately
complicated set of rules that emulate POSIX behavior.  Similarly, if
euid == 0 or ruid == 0, then fP, fI, and fE are modified differently
(primary, fP and fI usually end up being the full set).  For nonroot
users executing binaries with neither setuid nor file caps, fI and fP
are empty and fE is false.

As an extra complication, if you execute a process as nonroot and fE is
set, then the "secure exec" rules are in effect: AT_SECURE gets set,
LD_PRELOAD doesn't work, etc.

This is rather messy.  We've learned that making any changes is
dangerous, though: if a new kernel version allows an unprivileged
program to change its security state in a way that persists cross
execution of a setuid program or a program with file caps, this
persistent state is surprisingly likely to allow setuid or file-capped
programs to be exploited for privilege escalation.

===== The problem =====

Capability inheritance is basically useless.

If you aren't root and you execute an ordinary binary, fI is zero, so
your capabilities have no effect whatsoever on pP'.  This means that you
can't usefully execute a helper process or a shell command with elevated
capabilities if you aren't root.

On current kernels, you can sort of work around this by setting fI to
the full set for most or all non-setuid executable files.  This causes
pP' = pI for nonroot, and inheritance works.  No one does this because
it's a PITA and it isn't even supported on most filesystems.

If you try this, you'll discover that every nonroot program ends up with
secure exec rules, breaking many things.

This is a problem that has bitten many people who have tried to use
capabilities for anything useful.

===== The proposed change =====

This patch adds a fifth capability mask called the ambient mask (pA).
pA does what most people expect pI to do.

pA obeys the invariant that no bit can ever be set in pA if it is not
set in both pP and pI.  Dropping a bit from pP or pI drops that bit from
pA.  This ensures that existing programs that try to drop capabilities
still do so, with a complication.  Because capability inheritance is so
broken, setting KEEPCAPS, using setresuid to switch to nonroot uids, and
then calling execve effectively drops capabilities.  Therefore,
setresuid from root to nonroot conditionally clears pA unless
SECBIT_NO_SETUID_FIXUP is set.  Processes that don't like this can
re-add bits to pA afterwards.

The capability evolution rules are changed:

  pA' = (file caps or setuid or setgid ? 0 : pA)
  pP' = (X & fP) | (pI & fI) | pA'
  pI' = pI
  pE' = (fE ? pP' : pA')
  X is unchanged

If you are nonroot but you have a capability, you can add it to pA.  If
you do so, your children get that capability in pA, pP, and pE.  For
example, you can set pA = CAP_NET_BIND_SERVICE, and your children can
automatically bind low-numbered ports.  Hallelujah!

Unprivileged users can create user namespaces, map themselves to a
nonzero uid, and create both privileged (relative to their namespace)
and unprivileged process trees.  This is currently more or less
impossible.  Hallelujah!

You cannot use pA to try to subvert a setuid, setgid, or file-capped
program: if you execute any such program, pA gets cleared and the
resulting evolution rules are unchanged by this patch.

Users with nonzero pA are unlikely to unintentionally leak that
capability.  If they run programs that try to drop privileges, dropping
privileges will still work.

It's worth noting that the degree of paranoia in this patch could
possibly be reduced without causing serious problems.  Specifically, if
we allowed pA to persist across executing non-pA-aware setuid binaries
and across setresuid, then, naively, the only capabilities that could
leak as a result would be the capabilities in pA, and any attacker
*already* has those capabilities.  This would make me nervous, though --
setuid binaries that tried to privilege-separate might fail to do so,
and putting CAP_DAC_READ_SEARCH or CAP_DAC_OVERRIDE into pA could have
unexpected side effects.  (Whether these unexpected side effects would
be exploitable is an open question.) I've therefore taken the more
paranoid route.  We can revisit this later.

An alternative would be to require PR_SET_NO_NEW_PRIVS before setting
ambient capabilities.  I think that this would be annoying and would
make granting otherwise unprivileged users minor ambient capabilities
(CAP_NET_BIND_SERVICE or CAP_NET_RAW for example) much less useful than
it is with this patch.

===== Footnotes =====

[1] Files that are missing the "security.capability" xattr or that have
unrecognized values for that xattr end up with has_cap set to false.
The code that does that appears to be complicated for no good reason.

[2] The libcap capability mask parsers and formatters are dangerously
misleading and the documentation is flat-out wrong.  fE is *not* a mask;
it's a single bit.  This has probably confused every single person who
has tried to use file capabilities.

[3] Linux very confusingly processes both the script and the interpreter
if applicable, for reasons that elude me.  The results from thinking
about a script's file capabilities and/or setuid bits are mostly
discarded.

Preliminary userspace code is here, but it needs updating:
https://git.kernel.org/cgit/linux/kernel/git/luto/util-linux-playground.git/commit/?h=cap_ambient&id=7f5afbd175d2

Here is a test program that can be used to verify the functionality
(from Christoph):

/*
* Test program for the ambient capabilities. This program spawns a shell
* that allows running processes with a defined set of capabilities.
*
* (C) 2015 Christoph Lameter <cl@linux.com>
* Released under: GPL v3 or later.
*
*
* Compile using:
*
* gcc -o ambient_test ambient_test.o -lcap-ng
*
* This program must have the following capabilities to run properly:
* Permissions for CAP_NET_RAW, CAP_NET_ADMIN, CAP_SYS_NICE
*
* A command to equip the binary with the right caps is:
*
* setcap cap_net_raw,cap_net_admin,cap_sys_nice+p ambient_test
*
*
* To get a shell with additional caps that can be inherited by other processes:
*
* ./ambient_test /bin/bash
*
*
* Verifying that it works:
*
* From the bash spawed by ambient_test run
*
* cat /proc/$$/status
*
* and have a look at the capabilities.
*/

/*
* Definitions from the kernel header files. These are going to be removed
* when the /usr/include files have these defined.
*/

static void set_ambient_cap(int cap)
{
int rc;

capng_get_caps_process();
rc = capng_update(CAPNG_ADD, CAPNG_INHERITABLE, cap);
if (rc) {
printf("Cannot add inheritable cap\n");
exit(2);
}
capng_apply(CAPNG_SELECT_CAPS);

/* Note the two 0s at the end. Kernel checks for these */
if (prctl(PR_CAP_AMBIENT, PR_CAP_AMBIENT_RAISE, cap, 0, 0)) {
perror("Cannot set cap");
exit(1);
}
}

int main(int argc, char **argv)
{
int rc;

set_ambient_cap(CAP_NET_RAW);
set_ambient_cap(CAP_NET_ADMIN);
set_ambient_cap(CAP_SYS_NICE);

printf("Ambient_test forking shell\n");
if (execv(argv[1], argv + 1))
perror("Cannot exec");

return 0;
}

Change-Id: Ie7a1a33e9b98a2a3f1592c3bb682ceb6193ca2de
Signed-off-by: Christoph Lameter <cl@linux.com> # Original author
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
Acked-by: Kees Cook <keescook@chromium.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Aaron Jones <aaronmdjones@gmail.com>
Cc: Ted Ts'o <tytso@mit.edu>
Cc: Andrew G. Morgan <morgan@kernel.org>
Cc: Mimi Zohar <zohar@linux.vnet.ibm.com>
Cc: Austin S Hemmelgarn <ahferroin7@gmail.com>
Cc: Markku Savela <msa@moth.iki.fi>
Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>
Cc: James Morris <james.l.morris@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Origin: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=58319057b7847667f0c9585b9de0e8932b0fdb08
Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>

sec-reboot: Remove not supported reboot modes

Remove not supported reboot modes including recovery and fota.

Change-Id: Iac6953a4d735eeb96530870e62ca487695ee1a4c
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

mm: split ET_DYN ASLR from mmap ASLR

This fixes the "offset2lib" weakness in ASLR for arm, arm64, mips,
powerpc, and x86.  The problem is that if there is a leak of ASLR from
the executable (ET_DYN), it means a leak of shared library offset as
well (mmap), and vice versa.  Further details and a PoC of this attack
is available here:

  http://cybersecurity.upv.es/attacks/offset2lib/offset2lib.html

With this patch, a PIE linked executable (ET_DYN) has its own ASLR
region:

  $ ./show_mmaps_pie
  54859ccd6000-54859ccd7000 r-xp  ...  /tmp/show_mmaps_pie
  54859ced6000-54859ced7000 r--p  ...  /tmp/show_mmaps_pie
  54859ced7000-54859ced8000 rw-p  ...  /tmp/show_mmaps_pie
  7f75be764000-7f75be91f000 r-xp  ...  /lib/x86_64-linux-gnu/libc.so.6
  7f75be91f000-7f75beb1f000 ---p  ...  /lib/x86_64-linux-gnu/libc.so.6
  7f75beb1f000-7f75beb23000 r--p  ...  /lib/x86_64-linux-gnu/libc.so.6
  7f75beb23000-7f75beb25000 rw-p  ...  /lib/x86_64-linux-gnu/libc.so.6
  7f75beb25000-7f75beb2a000 rw-p  ...
  7f75beb2a000-7f75beb4d000 r-xp  ...  /lib64/ld-linux-x86-64.so.2
  7f75bed45000-7f75bed46000 rw-p  ...
  7f75bed46000-7f75bed47000 r-xp  ...
  7f75bed47000-7f75bed4c000 rw-p  ...
  7f75bed4c000-7f75bed4d000 r--p  ...  /lib64/ld-linux-x86-64.so.2
  7f75bed4d000-7f75bed4e000 rw-p  ...  /lib64/ld-linux-x86-64.so.2
  7f75bed4e000-7f75bed4f000 rw-p  ...
  7fffb3741000-7fffb3762000 rw-p  ...  [stack]
  7fffb377b000-7fffb377d000 r--p  ...  [vvar]
  7fffb377d000-7fffb377f000 r-xp  ...  [vdso]

The change is to add a call the newly created arch_mmap_rnd() into the
ELF loader for handling ET_DYN ASLR in a separate region from mmap ASLR,
as was already done on s390.  Removes CONFIG_BINFMT_ELF_RANDOMIZE_PIE,
which is no longer needed.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reported-by: Hector Marco-Gisbert <hecmargi@upv.es>
Cc: Russell King <linux@arm.linux.org.uk>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: "David A. Long" <dave.long@linaro.org>
Cc: Andrey Ryabinin <a.ryabinin@samsung.com>
Cc: Arun Chandran <achandran@mvista.com>
Cc: Yann Droneaud <ydroneaud@opteya.com>
Cc: Min-Hua Chen <orca.chen@gmail.com>
Cc: Paul Burton <paul.burton@imgtec.com>
Cc: Alex Smith <alex@alex-smith.me.uk>
Cc: Markos Chandras <markos.chandras@imgtec.com>
Cc: Vineeth Vijayan <vvijayan@mvista.com>
Cc: Jeff Bailey <jeffbailey@google.com>
Cc: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Cc: Ben Hutchings <ben@decadent.org.uk>
Cc: Behan Webster <behanw@converseincode.com>
Cc: Ismael Ripoll <iripoll@upv.es>
Cc: Jan-Simon Mller <dl9pf@gmx.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[sw0312.kim: back-port mainline commit d1fd836dcf00 to fix pie executable heap address issue]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I86d8daa6a489f61205cc97b465c43273460b0c66

mm: expose arch_mmap_rnd when available

When an architecture fully supports randomizing the ELF load location,
a per-arch mmap_rnd() function is used to find a randomized mmap base.
In preparation for randomizing the location of ET_DYN binaries
separately from mmap, this renames and exports these functions as
arch_mmap_rnd(). Additionally introduces CONFIG_ARCH_HAS_ELF_RANDOMIZE
for describing this feature on architectures that support it
(which is a superset of ARCH_BINFMT_ELF_RANDOMIZE_PIE, since s390
already supports a separated ET_DYN ASLR from mmap ASLR without the
ARCH_BINFMT_ELF_RANDOMIZE_PIE logic).

Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: Hector Marco-Gisbert <hecmargi@upv.es>
Cc: Russell King <linux@arm.linux.org.uk>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: "David A. Long" <dave.long@linaro.org>
Cc: Andrey Ryabinin <a.ryabinin@samsung.com>
Cc: Arun Chandran <achandran@mvista.com>
Cc: Yann Droneaud <ydroneaud@opteya.com>
Cc: Min-Hua Chen <orca.chen@gmail.com>
Cc: Paul Burton <paul.burton@imgtec.com>
Cc: Alex Smith <alex@alex-smith.me.uk>
Cc: Markos Chandras <markos.chandras@imgtec.com>
Cc: Vineeth Vijayan <vvijayan@mvista.com>
Cc: Jeff Bailey <jeffbailey@google.com>
Cc: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Cc: Ben Hutchings <ben@decadent.org.uk>
Cc: Behan Webster <behanw@converseincode.com>
Cc: Ismael Ripoll <iripoll@upv.es>
Cc: Jan-Simon Mller <dl9pf@gmx.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[sw0312.kim: back-port upstream commit 2b68f6caeac2 to apply upstream commit d1fd836dcf00 ("mm: split ET_DYN ASLR from mmap ASLR")]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I31089760dd503776dc0473b6bce777389e3d6a1e

mips: extract logic for mmap_rnd()

In preparation for splitting out ET_DYN ASLR, extract the mmap ASLR
selection into a separate function.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[sw0312.kim: cherry-pick mainline commit 1f0569df0b02 to apply upstream commit d1fd836dcf00 ("mm: split ET_DYN ASLR from mmap ASLR")]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I31d702f23decd92d5f3654c76f44a4b83aac9de0

arm: factor out mmap ASLR into mmap_rnd

To address the "offset2lib" ASLR weakness[1], this separates ET_DYN ASLR
from mmap ASLR, as already done on s390. The architectures that are
already randomizing mmap (arm, arm64, mips, powerpc, s390, and x86), have
their various forms of arch_mmap_rnd() made available via the new
CONFIG_ARCH_HAS_ELF_RANDOMIZE. For these architectures,
arch_randomize_brk() is collapsed as well.

This is an alternative to the solutions in:
https://lkml.org/lkml/2015/2/23/442

I've been able to test x86 and arm, and the buildbot (so far) seems happy
with building the rest.

[1] http://cybersecurity.upv.es/attacks/offset2lib/offset2lib.html

This patch (of 10):

In preparation for splitting out ET_DYN ASLR, this moves the ASLR
calculations for mmap on ARM into a separate routine, similar to x86.
This also removes the redundant check of personality (PF_RANDOMIZE is
already set before calling arch_pick_mmap_layout).

Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: Hector Marco-Gisbert <hecmargi@upv.es>
Cc: Russell King <linux@arm.linux.org.uk>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: "David A. Long" <dave.long@linaro.org>
Cc: Andrey Ryabinin <a.ryabinin@samsung.com>
Cc: Arun Chandran <achandran@mvista.com>
Cc: Yann Droneaud <ydroneaud@opteya.com>
Cc: Min-Hua Chen <orca.chen@gmail.com>
Cc: Paul Burton <paul.burton@imgtec.com>
Cc: Alex Smith <alex@alex-smith.me.uk>
Cc: Markos Chandras <markos.chandras@imgtec.com>
Cc: Vineeth Vijayan <vvijayan@mvista.com>
Cc: Jeff Bailey <jeffbailey@google.com>
Cc: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Cc: Ben Hutchings <ben@decadent.org.uk>
Cc: Behan Webster <behanw@converseincode.com>
Cc: Ismael Ripoll <iripoll@upv.es>
Cc: Jan-Simon Mller <dl9pf@gmx.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[sw0312.kim : cherry-pick mainline commit fbbc400f3924 to apply upstream commit d1fd836dcf00 ("mm: split ET_DYN ASLR from mmap ASLR")]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I13d0bd2960de3d875acd1124d5fda10241521e15

arm: dts: sprd-scx35-tizen_z3: Change battery check type

To show battery presence always true whether real battery is connected
or not, change battery check type to "CHECK_NONE".

Change-Id: I3ab30eab60e721578dbb940ba74d7798c8801843
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>

ARM: tizen_tm1_defconfig: Disable ANDROID_LOGGER

Disable CONFIG_ANDROID_LOGGER.

Change-Id: Ib68ac1a3009abd0ae5e7b0c50a33aac616380ea7
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>

ARM: defconfig: disable SECURITY_SMACK_NETFILTER config

Disable SECURITY_SMACK_NETFILTER configuration.

Change-Id: I5c37cce55d35dd8ca024815b6c92afcaa18f0525
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>

wlan: sc2331: Fix to return error on timeout

When nl80211 command timed out, the driver should return error.
The state of data structure in the driver should be updated
only when it succeed.

Change-Id: I31e3440e442531eb6136d09e5bb8069c1da09daf
Signed-off-by: Semun Lee <semun.lee@samsung.com>

ARM: tizen_tm1_defconfig: Enable SW_SYNC

Tizen display manager and buffer module tbm and its hal layer
library can use SW_SYNC to synchronize rendering and display
explicitly but only TM1 target does not have SW_SYNC enabled
kernel. To use SW_SYNC usage in tbm commonly, enable SW_SYNC
for TM1 also.

Change-Id: I22a7a17b9d54cc02c3d6fd4677db7d978783e6cc
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

usb: dwc_otg: Remove unused diepctl

After the commit fdbf8e9fb37e ("usb: dwc_otg: Fix possible
misbehavior during pcd reset"), diepctl is not used anymore
and it causes build warning. Remove unused diepctl variable.

Change-Id: I631fd03fb2e42cd9f7802d4c14839eedf19fbdbe
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

usb: dwc_otg: Fix possible misbehavior during pcd reset

The peripheral controller cannot occasionally, especially in first
boot right after the target is flashed with new images, provide
descriptor after usb reset when the gadget driver is composed with
multiple functions such as sdb and mtp.

I found the problem can be resolved by getting rid of possible
unnecessary works on reset interrupt handler. Removed jobs in this
commit consist of two parts: rxfifo flush and set DPID with DATA0.
Though I cannot figure out how two jobs influence on the reset
behavior, removing these seems quite reasonable since two parts are not
used anywhere in similar dwc vendor drivers. In addition, this just
changes behavior of reset interrupt handler, so other functionalities
are not affected.

Change-Id: I7ab93bb60331e27ece62bb9d5e8e01b1591cf2dc
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>

arm: mach-sc: usb_switch: report attached and detached usb state only

The sm5504 muic recognizes high current usb cable as CDP, Charging
Downstream Port as value 2 and usb_switch reported the value to
user. But Tizen deviced never expects usb state except attached(1)
and detached(0) and this causes usb connection failure. Fix to
report attached and detached usb state only from usb_switch.

Change-Id: I619d1af72e97120a16f0e88e5b1147b968511c41
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

ARM: tizen_tm1_defconfig: Sync for BTRFS ZSTD support

After patch series supporting BTRFS ZSTD, auto-generated defconfig
has XXHASH, ZSTD_COMPRESS and ZSTD_DECOMPRESS config options. Sync
for the BTRFS ZSTD support options.

Change-Id: If5b73c140ff7739781708115569f0fb5fa29ae53
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

btrfs: Add zstd support

Add zstd compression and decompression support to BtrFS. zstd at its
fastest level compresses almost as well as zlib, while offering much
faster compression and decompression, approaching lzo speeds.

I benchmarked btrfs with zstd compression against no compression, lzo
compression, and zlib compression. I benchmarked two scenarios. Copying
a set of files to btrfs, and then reading the files. Copying a tarball
to btrfs, extracting it to btrfs, and then reading the extracted files.
After every operation, I call `sync` and include the sync time.
Between every pair of operations I unmount and remount the filesystem
to avoid caching. The benchmark files can be found in the upstream
zstd source repository under
`contrib/linux-kernel/{btrfs-benchmark.sh,btrfs-extract-benchmark.sh}`
[1] [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.

The first compression benchmark is copying 10 copies of the unzipped
Silesia corpus [3] into a BtrFS filesystem mounted with
`-o compress-force=Method`. The decompression benchmark times how long
it takes to `tar` all 10 copies into `/dev/null`. The compression ratio is
measured by comparing the output of `df` and `du`. See the benchmark file
[1] for details. I benchmarked multiple zstd compression levels, although
the patch uses zstd level 1.

| Method  | Ratio | Compression MB/s | Decompression speed |
|---------|-------|------------------|---------------------|
| None    |  0.99 |              504 |                 686 |
| lzo     |  1.66 |              398 |                 442 |
| zlib    |  2.58 |               65 |                 241 |
| zstd 1  |  2.57 |              260 |                 383 |
| zstd 3  |  2.71 |              174 |                 408 |
| zstd 6  |  2.87 |               70 |                 398 |
| zstd 9  |  2.92 |               43 |                 406 |
| zstd 12 |  2.93 |               21 |                 408 |
| zstd 15 |  3.01 |               11 |                 354 |

The next benchmark first copies `linux-4.11.6.tar` [4] to btrfs. Then it
measures the compression ratio, extracts the tar, and deletes the tar.
Then it measures the compression ratio again, and `tar`s the extracted
files into `/dev/null`. See the benchmark file [2] for details.

| Method | Tar Ratio | Extract Ratio | Copy (s) | Extract (s)| Read (s) |
|--------|-----------|---------------|----------|------------|----------|
| None   |      0.97 |          0.78 |    0.981 |      5.501 |    8.807 |
| lzo    |      2.06 |          1.38 |    1.631 |      8.458 |    8.585 |
| zlib   |      3.40 |          1.86 |    7.750 |     21.544 |   11.744 |
| zstd 1 |      3.57 |          1.85 |    2.579 |     11.479 |    9.389 |

[1] https://github.com/facebook/zstd/blob/dev/contrib/linux-kernel/btrfs-benchmark.sh
[2] https://github.com/facebook/zstd/blob/dev/contrib/linux-kernel/btrfs-extract-benchmark.sh
[3] http://sun.aei.polsl.pl/~sdeor/index.php?page=silesia
[4] https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.11.6.tar.xz

zstd source repository: https://github.com/facebook/zstd

Signed-off-by: Nick Terrell <terrelln@fb.com>
Signed-off-by: Chris Mason <clm@fb.com>
[jhoon20.kim: Modify some codes from the upstream to apply the btrfs
zstd compression in Linux 3.10 TM1 kernel]
Signed-off-by: Junghoon Kim <jhoon20.kim@samsung.com>
Change-Id: I610223ce816a11379d8bbf732d82978dfa917e98

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>
[jhoon20.kim: Backport from the upstream for the zstd compression]
Signed-off-by: Junghoon Kim <jhoon20.kim@samsung.com>
Change-Id: I1544fe051447cee776219b6cec92b8d24823196f

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>
[jhoon20.kim: Backport from the upstream for the zstd compression]
Signed-off-by: Junghoon Kim <jhoon20.kim@samsung.com>
Change-Id: I8cb946426afd1623cd44a20dc21ee8a21b365f2a

ARM: tizen_tm1_defconfig: Disable RAID6_PQ_BENCHMARK

Skip the algorithm benchmarking process of RAID6. This is helpful for
systems where fast kernel startup is important. Also, The option is not
crucial for the TM1 mobile device.

Change-Id: I90012c671bf064d175b26e3069e099577ff3333e
Signed-off-by: Junghoon Kim <jhoon20.kim@samsung.com>

lib/raid6: add option to skip algo benchmarking

This is helpful for systems where fast startup time is important.
It is especially nice to avoid benchmarking RAID functions that are
never used (for example, BTRFS selects RAID6_PQ even if the parity RAID
mode is not in use).

This saves 250+ milliseconds of boot time on modern x86 and ARM systems
with a dozen or more available implementations.

The new option is defaulted to 'y' to match the previous behavior of
always benchmarking on init.

Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Signed-off-by: Shaohua Li <shli@fb.com>
[jhoon20.kim: backport from mainline for the fast kernel startup]

Change-Id: I38c270c413d60de65f27cf9c95d44bb2e2d07ac2
Signed-off-by: Junghoon Kim <jhoon20.kim@samsung.com>

ARM: tizen_tm1_defconfig: Enable btrfs filesystem

Enable the btrfs filesystem in order to support btrfs rootfs image.

Change-Id: I52644e12ae74a1b43e4b73580753c0d0bbab50d1
Signed-off-by: Junghoon Kim <jhoon20.kim@samsung.com>

build: Export CROSS_COMPILE for the ARM target build

Export CROSS_COMPILE for the ARM target build.

Change-Id: I3db98a2bd939a97d3ad4e1932f8b1514dc131371
Signed-off-by: Junghoon Kim <jhoon20.kim@samsung.com>

include/linux/module.h: copy __init/__exit attrs to init/cleanup_module

The upcoming GCC 9 release extends the -Wmissing-attributes warnings
(enabled by -Wall) to C and aliases: it warns when particular function
attributes are missing in the aliases but not in their target.

In particular, it triggers for all the init/cleanup_module
aliases in the kernel (defined by the module_init/exit macros),
ending up being very noisy.

These aliases point to the __init/__exit functions of a module,
which are defined as __cold (among other attributes). However,
the aliases themselves do not have the __cold attribute.

Since the compiler behaves differently when compiling a __cold
function as well as when compiling paths leading to calls
to __cold functions, the warning is trying to point out
the possibly-forgotten attribute in the alias.

In order to keep the warning enabled, we decided to silence
this case. Ideally, we would mark the aliases directly
as __init/__exit. However, there are currently around 132 modules
in the kernel which are missing __init/__exit in their init/cleanup
functions (either because they are missing, or for other reasons,
e.g. the functions being called from somewhere else); and
a section mismatch is a hard error.

A conservative alternative was to mark the aliases as __cold only.
However, since we would like to eventually enforce __init/__exit
to be always marked, we chose to use the new __copy function
attribute (introduced by GCC 9 as well to deal with this).
With it, we copy the attributes used by the target functions
into the aliases. This way, functions that were not marked
as __init/__exit won't have their aliases marked either,
and therefore there won't be a section mismatch.

Note that the warning would go away marking either the extern
declaration, the definition, or both. However, we only mark
the definition of the alias, since we do not want callers
(which only see the declaration) to be compiled as if the function
was __cold (and therefore the paths leading to those calls
would be assumed to be unlikely).

Link: https://lore.kernel.org/lkml/20190123173707.GA16603@gmail.com/
Link: https://lore.kernel.org/lkml/20190206175627.GA20399@gmail.com/
Suggested-by: Martin Sebor <msebor@gcc.gnu.org>
Acked-by: Jessica Yu <jeyu@kernel.org>
Signed-off-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
[sw0312.kim: cherry-pick mainline commit a6e60d84989f for gcc 9 build
- apply to include/linux/init.h instead of include/linux/module.h]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: Ie56e11a14dca88e7cabd09b894a6428f9ffadb73

Compiler Attributes: add support for __copy (gcc >= 9)

commit c0d9782f5b6d7157635ae2fd782a4b27d55a6013 upstream.

From the GCC manual:

  copy
  copy(function)

    The copy attribute applies the set of attributes with which function
    has been declared to the declaration of the function to which
    the attribute is applied. The attribute is designed for libraries
    that define aliases or function resolvers that are expected
    to specify the same set of attributes as their targets. The copy
    attribute can be used with functions, variables, or types. However,
    the kind of symbol to which the attribute is applied (either
    function or variable) must match the kind of symbol to which
    the argument refers. The copy attribute copies only syntactic and
    semantic attributes but not attributes that affect a symbol’s
    linkage or visibility such as alias, visibility, or weak.
    The deprecated attribute is also not copied.

  https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html

The upcoming GCC 9 release extends the -Wmissing-attributes warnings
(enabled by -Wall) to C and aliases: it warns when particular function
attributes are missing in the aliases but not in their target, e.g.:

    void __cold f(void) {}
    void __alias("f") g(void);

diagnoses:

    warning: 'g' specifies less restrictive attribute than
    its target 'f': 'cold' [-Wmissing-attributes]

Using __copy(f) we can copy the __cold attribute from f to g:

    void __cold f(void) {}
    void __copy(f) __alias("f") g(void);

This attribute is most useful to deal with situations where an alias
is declared but we don't know the exact attributes the target has.

For instance, in the kernel, the widely used module_init/exit macros
define the init/cleanup_module aliases, but those cannot be marked
always as __init/__exit since some modules do not have their
functions marked as such.

Suggested-by: Martin Sebor <msebor@gcc.gnu.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[sw0312.kim: cherry-pick stable linux-4.14.y commit b00c958ceb6c for gcc 9 build
- change file path to include/linux/compiler.h instead of include/linux/compiler_types.h]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I0f0a016641391233166e04517ec70e24255d3ee9

kmsg: Remove unnecessary copy from creating predefined log dict

Creating predefined _COMM keywords in kmsg log dict has unnecessary
copy for task comm, to avoid build issue, in the commit b621c1cdcea7
("kmsg: Use TASK_COMM_LEN size buffer for get_task_comm()").
Remove the unnecessary string copy from creating predefined kmsg
log dict.

Change-Id: I7547487497e7f3acdab452586f97cf947fc1e6db
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

exec: avoid gcc-8 warning for get_task_comm

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>
[sw0312.kim: cherry-pick mainline commit 3756f6401c30 for gcc 9 build]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: Id98efe5de4803db524b4a39a140be13709c9b19f

kmsg: Use TASK_COMM_LEN size buffer for get_task_comm()

To avoid gcc-8 warning, get_task_comm() is fixed to check size of
buffer from the mainline commit 3756f6401c30 ("exec: avoid gcc-8
warning for get_task_comm"). To apply the commit, use
TASK_COMM_LEN size buffer for get_task_comm() in set_kmsg_dict().

Afte the mainline commit is applied, newly added unnecessary copy
will be removed properly.

Change-Id: Ic9a55c667143d5311e1e01c4ec9b44c7f2148eae
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

regmap: Remove attribute packed from struct 'regcache_rbtree_node'

On one hand commit 28644c809f44 ("regmap: Add the rbtree cache support")
added 'regcache_rbtree_node' as packed structure, while on the other hand
commit e977145aeaad ("[RBTREE] Add explicit alignment to sizeof(long)
for struct rb_node.") declared struct 'rb_node' as aligned.

Solve the ambiguity of placing aligned structure in a packed one by
removing the packed attribute from struct. This seems to be the behavior
of gcc anyway.

This removes the following warning (W=1):

drivers/base/regmap/regcache-rbtree.c:36:1: warning: alignment 1 of 'struct regcache_rbtree_node' is less than 4 [-Wpacked-not-aligned]

Cc: Dimitris Papastamos <dp@opensource.wolfsonmicro.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Mathieu Malaterre <malat@debian.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
[dongkyun.s: cherry-pick mainline commit 435bba0f11f0 for gcc 9 build]
Signed-off-by: Dongkyun Son <dongkyun.s@samsung.com>
Change-Id: Ic59dfc79db0973ccb387e7ced3bda05a674850d9

unifdef: use memcpy instead of strncpy

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>
[dongkyun.s: cherry-pick mainline commit 38c7b224ce22 for gcc 9 build]
Signed-off-by: Dongkyun Son <dongkyun.s@samsung.com>
Change-Id: Ie3f0328484a587ce010e02f19cbe162632fb1650

ip_tunnel: Fix name string concatenate in __ip_tunnel_create()

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>
[sw0312.kim: cherry-pick mainline commit 000ade80164 for gcc 9 build]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: Iea412bf5398b91fcdc471952a289d406ea26d677

usb: core: Replace hardcoded check with inline function from usb.h

Expression (urb->transfer_flags & URB_DIR_MASK) == URB_DIR_IN can be
replaced by usb_urb_dir_in(struct urb *urb) from usb.h for better
readability.

Signed-off-by: Keyur Patel <iamkeyur96@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[sw0312.kim: cherry-pick mainline commit 79595a734a68 for gcc 9 build]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: Ibd79606327c9609091e0f3ed3c7c97ac693a4adb

usb: gadget: dummy: fix nonsensical comparisons

gcc-8 points out two comparisons that are clearly bogus
and almost certainly not what the author intended to write:

drivers/usb/gadget/udc/dummy_hcd.c: In function 'set_link_state_by_speed':
drivers/usb/gadget/udc/dummy_hcd.c:379:31: error: bitwise comparison always evaluates to false [-Werror=tautological-compare]
         USB_PORT_STAT_ENABLE) == 1 &&
                               ^~
drivers/usb/gadget/udc/dummy_hcd.c:381:25: error: bitwise comparison always evaluates to false [-Werror=tautological-compare]
      USB_SS_PORT_LS_U0) == 1 &&
                         ^~

I looked at the code for a bit and came up with a change that makes
it look like what the author probably meant here. This makes it
look reasonable to me and to gcc, shutting up the warning.

It does of course change behavior as the two conditions are actually
evaluated rather than being hardcoded to false, and I have made no
attempt at verifying that the changed logic makes sense in the context
of a USB HCD, so that part needs to be reviewed carefully.

Fixes: 1cd8fd2887e1 ("usb: gadget: dummy_hcd: add SuperSpeed support")
Cc: Tatyana Brokhman <tlinder@codeaurora.org>
Cc: Felipe Balbi <balbi@kernel.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
[sw0312.kim: cherry-pick mainline commit 7661ca09b2ff for gcc 9 build
- change file path to drivers/usb/gadget/dummy_hcd.c]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I5bfba1d02743b27940d6e457fe22d254727dea29

ARM: fix put_user() for gcc-8

Building kernels before linux-4.7 with gcc-8 results in many build failures
when gcc triggers a check that was meant to catch broken compilers:

/tmp/ccCGMQmS.s:648: Error: .err encountered

According to the discussion in the gcc bugzilla, a local "register
asm()" variable is still supposed to be the correct way to force an
inline assembly to use a particular register, but marking it 'const'
lets the compiler do optimizations that break that, i.e the compiler is
free to treat the variable as either 'const' or 'register' in that case.

Upstream commit 9f73bd8bb445 ("ARM: uaccess: remove put_user() code
duplication") fixed this problem in linux-4.8 as part of a larger change,
but seems a little too big to be backported to 4.4.

Let's take the simplest fix and change only the one broken line in the
same way as newer kernels.

Suggested-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85745
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86673
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Johannes Pointner <h4nn35.work@gmail.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
[sw0312.kim: backport stable linux-3.16.y commit 5f8f9f872097 for gcc 9 build]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: Ifa7372959ae576f32543605101530cbf66893ce5

gcc-9: silence 'address-of-packed-member' warning

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>
[sw0312.kim: cherry-pick mainline commit 6f303d60534c for gcc 9 build]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I2e4fb85329412ecf3acdeee02ae44bb3082ce921

kconfig: Avoid format overflow warning from GCC 8.1

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.

Cc: stable@vger.kernel.org
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
[sw0312.kim: cherry-pick mainline commit 2ae89c7a82ea for gcc 9 build]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: Idc92085d7c4ecf6e37ad428ce524bb414442793d

gen_init_cpio: avoid NULL pointer dereference and rework env expanding

getenv() may return NULL if given environment variable does not exist
which leads to NULL dereference when calling strncat.

Besides that, the environment variable name was copied to a temporary
env_var buffer, but this copying can be avoided by simply using the input
string.

Lastly, the whole loop can be greatly simplified by using the snprintf
function instead of the playing with strncat.

By the way, the current implementation allows a recursive variable
expansion, as in:

$ echo 'out ${A} out ' | A='a ${B} a' B=b /tmp/a
out a b a out

I'm assuming this is just a side effect and not a conscious decision
(especially as this may lead to infinite loop), but I didn't want to
change this behaviour without consulting.

If the current behaviour is deamed incorrect, I'll be happy to send
a patch without recursive processing.

Signed-off-by: Michal Nazarewicz <mina86@mina86.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Jesper Juhl <jj@codesealer.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[dongkyun.s: cherry-pick mainline commit c725ee54c30b for gcc 9 build]
Signed-off-by: Dongkyun Son <dongkyun.s@samsung.com>
Change-Id: I16e6c2691b3e67651de4bee374c1fab87606337c

give up on gcc ilog2() constant optimizations

gcc-7 has an "optimization" pass that completely screws up, and
generates the code expansion for the (impossible) case of calling
ilog2() with a zero constant, even when the code gcc compiles does not
actually have a zero constant.

And we try to generate a compile-time error for anybody doing ilog2() on
a constant where that doesn't make sense (be it zero or negative).  So
now gcc7 will fail the build due to our sanity checking, because it
created that constant-zero case that didn't actually exist in the source
code.

There's a whole long discussion on the kernel mailing about how to work
around this gcc bug.  The gcc people themselevs have discussed their
"feature" in

   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72785

but it's all water under the bridge, because while it looked at one
point like it would be solved by the time gcc7 was released, that was
not to be.

So now we have to deal with this compiler braindamage.

And the only simple approach seems to be to just delete the code that
tries to warn about bad uses of ilog2().

So now "ilog2()" will just return 0 not just for the value 1, but for
any non-positive value too.

It's not like I can recall anybody having ever actually tried to use
this function on any invalid value, but maybe the sanity check just
meant that such code never made it out in public.

Reported-by: Laura Abbott <labbott@redhat.com>
Cc: John Stultz <john.stultz@linaro.org>,
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[dongkyun.s: cherry-pick mainline commit 474c90156c8d for gcc 9 build]
Signed-off-by: Dongkyun Son <dongkyun.s@samsung.com>
Change-Id: Ie054a0dce237f09ddc56f0e3b5973798b28e0aae

Smack: Verify read access on file open - v3

Smack believes that many of the operatons that can
be performed on an open file descriptor are read operations.
The fstat and lseek system calls are examples.
An implication of this is that files shouldn't be open
if the task doesn't have read access even if it has
write access and the file is being opened write only.

Targeted for git://git.gitorious.org/smack-next/kernel.git

Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
[sw0312.kim: cherry-pick mainline commit a6834c0b9114 to apply open to read access]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: Ifafc642de9393f45e2b0aabd94bb1058bbe99af6

ARM: tizen_tm1_defconfig: enable MATCH_OWNER xtables module

Enable the MATCH_OWNER xtables module to be compiled for using
xt_owner supplementary groups.

Change-Id: I188f140b83b6ab0c0f546f77a67d0cbedfafab49
Signed-off-by: Lukasz Pawelczyk <l.pawelczyk@samsung.com>
[sw0312.kim: split patch for backport and change of defconfig]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

netfilter: xt_owner: A fix for backport of 'xt_owner: Add supplementary groups option'

This patch fixes the backport of 'netfilter: xt_owner: Add
supplementary groups option' (97f200a99f31).

Change-Id: Iad7b418057c27b95bf04b12d042bb604bd721997
Signed-off-by: Lukasz Pawelczyk <l.pawelczyk@samsung.com>
[sw0312.kim: split fix for backport and change of defconfig]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

netfilter: xt_owner: bail out with EINVAL in case of unsupported flags

Reject flags that are not supported with EINVAL.

Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
[sw0312.kim: backport from mainline to support supplementary groups on netfilter]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I6d86e2db548445d29405fb9cbec540f7d1a196ef

netfilter: xt_owner: Add supplementary groups option

The XT_OWNER_SUPPL_GROUPS flag causes GIDs specified with XT_OWNER_GID
to be also checked in the supplementary groups of a process.

f_cred->group_info cannot be modified during its lifetime and f_cred
holds a reference to it so it's safe to use.

Signed-off-by: Lukasz Pawelczyk <l.pawelczyk@samsung.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
[sw0312.kim: backport from mainline to apply supplementary groups on netfilter]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: Ib0e14affa03a612ea85dd409a2de00d7d2cbb061

input: ist3xx: Fixes string buffer overflow

The string buffer has page size but sizeof returns 4.

Fixes: 81925d011289 ("input: ist3xx: replace misused strncat with s(n)printf")
Change-Id: Ia2272b385e510fd5a4df944ce19b3fe64220896a
Signed-off-by: Jaechul Lee <jcsing.lee@samsung.com>

media: radio: sprd: fix only requesting to get snr when used

When not used, requesting to get snr causes following kernel panic
because driver is not initialized. Fix only requesting to get snr
when used.

   Internal error: Oops: 805 [#1] PREEMPT SMP ARM
   ...
   [<c05a9fd8>] (skb_queue_tail+0x34/0x58) from [<c047e7e4>] (__fm_send_cmd.isra.0+0xcc/0xf8)
   [<c047e7e4>] (__fm_send_cmd.isra.0+0xcc/0xf8) from [<c047ea5c>] (fmc_send_cmd+0x6c/0x210)
   [<c047ea5c>] (fmc_send_cmd+0x6c/0x210) from [<c0482764>] (fm_rx_get_snr+0x4c/0x84)
   [<c0482764>] (fm_rx_get_snr+0x4c/0x84) from [<c0480ad4>] (show_fmrx_curr_snr+0x34/0x6c)
   [<c0480ad4>] (show_fmrx_curr_snr+0x34/0x6c) from [<c0308264>] (dev_attr_show+0x30/0x54)
   [<c0308264>] (dev_attr_show+0x30/0x54) from [<c0172498>] (sysfs_read_file+0xc0/0x170)
   [<c0172498>] (sysfs_read_file+0xc0/0x170) from [<c01160b8>] (vfs_read+0xbc/0x138)
   [<c01160b8>] (vfs_read+0xbc/0x138) from [<c01166a8>] (SyS_read+0x50/0x78)
   [<c01166a8>] (SyS_read+0x50/0x78) from [<c000fa4c>] (__sys_trace_return+0x0/0x14)

Change-Id: I6ada090c40925212ef96107d56021612c5cf46fe
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

packaging: fix to strip kernel modules

Fix to strip kernel modules with INSTALL_MOD_STRIP=1 option for
modules_install.

Change-Id: I9e15dedadd46506d368231c22fef12dabdc61d55
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

build: scripts: fix to strip kernel modules

Fix to strip kernel modules from build script.

Change-Id: I25f79594813ea6220f98175daee3d4de58e3af38
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

usb: gadget: f_fs: remove global epin/epout fileio completion

In product code, global epin/epi fileio completion is applied but
if more than one multiple instance of functionfs are used, the
global completions cause transfer error. Remove global epin/epout
fileio to resolve transfer error in functionfs.

Change-Id: Ic71b34bbc83e0cfd9e76321fc4b8f86c2e259bfd
Signed-off-by: INSUN PYO <insun.pyo@samsung.com>
[sw0312.kim: rebase and remove related unnecessary part also]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

ARM: tizen_tm1_defconfig: enable FUNCTION_TRACER

To trace kernel function calls, enable FUNCTION_TRACER config.

Change-Id: I6caabf29f26f2b7340c4a1358e7f619775269e9c
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

input: mms134s: remove unnecessary KERN log level from pr_* functions

Remove unnecessary KERN log level from pr_* functions.

Change-Id: If97b8c96d0f011b0b4f6a7fd24dd91fe819123c0
Reported-by: Insun Pyo <insun.pyo@samsung.com>
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

sprd: remove unnecessary KERN log level from pr_* functions

Remove unnecessary KERN log level from pr_* functions.

Change-Id: I67d1315fe0d51450ea16c2340aff81fd8049040d
Reported-by: Insun Pyo <insun.pyo@samsung.com>
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

HID: samsung: move unexecuted statements

In game pad event handling, there are unexecuted statements
because of wrong position. Move the statements properly.

Change-Id: Ifc7240718231539020119743fb7fb5fb8d5d0e7b
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

power: load_analyzer: fix pointer-compare build warning

Fix following pointer-compare build warning with gcc 7:
In file included from drivers/power/load_analyzer_main.c:79:0:
   drivers/power/load_analyzer_input.c: In function ‘input_rec_store_input_dev_info’:
   drivers/power/load_analyzer_input.c:32:17: warning: comparison between pointer and zero character constant [-Wpointer-compare]
      if (dev->name == '\0')
                    ^~
   drivers/power/load_analyzer_input.c:32:7: note: did you mean to dereference the pointer?
      if (dev->name == '\0')
          ^

Change-Id: I48c4028cb8ff5ddd9d23288f4d452f0eb14eb692
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

disable new gcc-7.1.1 warnings for now

I made the mistake of upgrading my desktop to the new Fedora 26 that
comes with gcc-7.1.1.

There's nothing wrong per se that I've noticed, but I now have 1500
lines of warnings, mostly from the new format-truncation warning
triggering all over the tree.

We use 'snprintf()' and friends in a lot of places, and often know that
the numbers are fairly small (ie a controller index or similar), but gcc
doesn't know that, and sees an 'int', and thinks that it could be some
huge number. And then complains when our buffers are not able to fit
the name for the ten millionth controller.

These warnings aren't necessarily bad per se, and we probably want to
look through them subsystem by subsystem, but at least during the merge
window they just mean that I can't even see if somebody is introducing
any *real* problems when I pull.

So warnings disabled for now.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[sw0312.kim: cherry-pick from mainline to fix build warning with gcc 7]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: Idfb16c6d8a06d040acb3488fe1d304ca8468dc24

ARM: tizen_tm1_defconfig: enable SND_USB_AUDIO

SND_USB_AUDIO configuration is enabled for supporting usb audio devices.

Change-Id: I9d298e4723b472622b95158649abc24a5c3e4d1f
Signed-off-by: Jaechul Lee <jcsing.lee@samsung.com>

Bluetooth: Report RPA changed event

When RPA changed, The updated RPA is not applied on
VSC advertising. This patchset generates new event
and resolves the problem.

Change-Id: Icc3dd74da0449cb8e456c27bc34995f43326efe1
Signed-off-by: injun.yang <injun.yang@samsung.com>
Signed-off-by: DoHyun Pyun <dh79.pyun@samsung.com>

Bluetooth: Fix hci unintended disconnect issue

hci connection is disconnected unintentionally because of
short timer in case link key is existing on legacy pairing mode.
Fix timer regardless of existence of link key.

Change-Id: Id66362347d89fdd3e2914a13df98e8e14e558fea
Signed-off-by: Wootak Jung <wootak.jung@samsung.com>

USB: core: Add type-specific length check of BOS descriptors

commit 81cf4a45360f70528f1f64ba018d61cb5767249a upstream.

As most of BOS descriptors are longer in length than their header
'struct usb_dev_cap_header', comparing solely with it is not sufficient
to avoid out-of-bounds access to BOS descriptors.

This patch adds descriptor type specific length check in
usb_get_bos_descriptor() to fix the issue.

Signed-off-by: Masakazu Mokuno <masakazu.mokuno@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[bwh: Backported to 3.16: drop handling of USB_PTM_CAP_TYPE and USB_SSP_CAP_TYPE]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
[sw0312.kim: cherry-pick from linux-3.16.y to fix usb issue related with CVE-2017-16531]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: Id446c97db292f11c48895b95e756bb0c7104a43b

USB: core: prevent malicious bNumInterfaces overflow

commit 48a4ff1c7bb5a32d2e396b03132d20d552c0eca7 upstream.

A malicious USB device with crafted descriptors can cause the kernel
to access unallocated memory by setting the bNumInterfaces value too
high in a configuration descriptor. Although the value is adjusted
during parsing, this adjustment is skipped in one of the error return
paths.

This patch prevents the problem by setting bNumInterfaces to 0
initially. The existing code already sets it to the proper value
after parsing is complete.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
[sw0312.kim: cherry-pick from linux-3.16.y to fix usb issue related with CVE-2017-16531]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: Id256d4802f9db3013b7abcc19652304e1c5a2b2f

USB: core: fix out-of-bounds access bug in usb_get_bos_descriptor()

commit 1c0edc3633b56000e18d82fc241e3995ca18a69e upstream.

Andrey used the syzkaller fuzzer to find an out-of-bounds memory
access in usb_get_bos_descriptor(). The code wasn't checking that the
next usb_dev_cap_header structure could fit into the remaining buffer
space.

This patch fixes the error and also reduces the bNumDeviceCaps field
in the header to match the actual number of capabilities found, in
cases where there are fewer than expected.

Reported-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
[sw0312.kim: cherry-pick from linux-3.16.y to fix usb issue related with CVE-2017-16531]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I85edcdcda17564d1c2e92e6980d27b34eacb5d4b

USB: fix out-of-bounds in usb_set_configuration

commit bd7a3fe770ebd8391d1c7d072ff88e9e76d063eb upstream.

Andrey Konovalov reported a possible out-of-bounds problem for a USB interface
association descriptor. He writes:
It seems there's no proper size check of a USB_DT_INTERFACE_ASSOCIATION
descriptor. It's only checked that the size is >= 2 in
usb_parse_configuration(), so find_iad() might do out-of-bounds access
to intf_assoc->bInterfaceCount.

And he's right, we don't check for crazy descriptors of this type very well, so
resolve this problem. Yet another issue found by syzkaller...

Reported-by: Andrey Konovalov <andreyknvl@google.com>
Tested-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
[sw0312.kim: cherry-pick from linux-3.16.y to fix CVE-2017-16531]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I2413801c6cf5e9eeda0280ba859466d01f5fd9d9

dm: fix race between dm_get_from_kobject() and __dm_destroy()

commit b9a41d21dceadf8104812626ef85dc56ee8a60ed upstream.

The following BUG_ON was hit when testing repeat creation and removal of
DM devices:

    kernel BUG at drivers/md/dm.c:2919!
    CPU: 7 PID: 750 Comm: systemd-udevd Not tainted 4.1.44
    Call Trace:
     [<ffffffff81649e8b>] dm_get_from_kobject+0x34/0x3a
     [<ffffffff81650ef1>] dm_attr_show+0x2b/0x5e
     [<ffffffff817b46d1>] ? mutex_lock+0x26/0x44
     [<ffffffff811df7f5>] sysfs_kf_seq_show+0x83/0xcf
     [<ffffffff811de257>] kernfs_seq_show+0x23/0x25
     [<ffffffff81199118>] seq_read+0x16f/0x325
     [<ffffffff811de994>] kernfs_fop_read+0x3a/0x13f
     [<ffffffff8117b625>] __vfs_read+0x26/0x9d
     [<ffffffff8130eb59>] ? security_file_permission+0x3c/0x44
     [<ffffffff8117bdb8>] ? rw_verify_area+0x83/0xd9
     [<ffffffff8117be9d>] vfs_read+0x8f/0xcf
     [<ffffffff81193e34>] ? __fdget_pos+0x12/0x41
     [<ffffffff8117c686>] SyS_read+0x4b/0x76
     [<ffffffff817b606e>] system_call_fastpath+0x12/0x71

The bug can be easily triggered, if an extra delay (e.g. 10ms) is added
between the test of DMF_FREEING & DMF_DELETING and dm_get() in
dm_get_from_kobject().

To fix it, we need to ensure the test of DMF_FREEING & DMF_DELETING and
dm_get() are done in an atomic way, so _minor_lock is used.

The other callers of dm_get() have also been checked to be OK: some
callers invoke dm_get() under _minor_lock, some callers invoke it under
_hash_lock, and dm_start_request() invoke it after increasing
md->open_count.

Signed-off-by: Hou Tao <houtao1@huawei.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
[sw0312.kim: cherry-pick from linux-3.16.y to fix CVE-2017-18203]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: Ibb5d2d43f6ed7b98e4f73f99861bced6b06e0df7

crypto: hmac - require that the underlying hash algorithm is unkeyed

commit af3ff8045bbf3e32f1a448542e73abb4c8ceb6f1 upstream.

Because the HMAC template didn't check that its underlying hash
algorithm is unkeyed, trying to use "hmac(hmac(sha3-512-generic))"
through AF_ALG or through KEYCTL_DH_COMPUTE resulted in the inner HMAC
being used without having been keyed, resulting in sha3_update() being
called without sha3_init(), causing a stack buffer overflow.

This is a very old bug, but it seems to have only started causing real
problems when SHA-3 support was added (requires CONFIG_CRYPTO_SHA3)
because the innermost hash's state is ->import()ed from a zeroed buffer,
and it just so happens that other hash algorithms are fine with that,
but SHA-3 is not.  However, there could be arch or hardware-dependent
hash algorithms also affected; I couldn't test everything.

Fix the bug by introducing a function crypto_shash_alg_has_setkey()
which tests whether a shash algorithm is keyed.  Then update the HMAC
template to require that its underlying hash algorithm is unkeyed.

Here is a reproducer:

    #include <linux/if_alg.h>
    #include <sys/socket.h>

    int main()
    {
        int algfd;
        struct sockaddr_alg addr = {
            .salg_type = "hash",
            .salg_name = "hmac(hmac(sha3-512-generic))",
        };
        char key[4096] = { 0 };

        algfd = socket(AF_ALG, SOCK_SEQPACKET, 0);
        bind(algfd, (const struct sockaddr *)&addr, sizeof(addr));
        setsockopt(algfd, SOL_ALG, ALG_SET_KEY, key, sizeof(key));
    }

Here was the KASAN report from syzbot:

    BUG: KASAN: stack-out-of-bounds in memcpy include/linux/string.h:341  [inline]
    BUG: KASAN: stack-out-of-bounds in sha3_update+0xdf/0x2e0  crypto/sha3_generic.c:161
    Write of size 4096 at addr ffff8801cca07c40 by task syzkaller076574/3044

    CPU: 1 PID: 3044 Comm: syzkaller076574 Not tainted 4.14.0-mm1+ #25
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  Google 01/01/2011
    Call Trace:
      __dump_stack lib/dump_stack.c:17 [inline]
      dump_stack+0x194/0x257 lib/dump_stack.c:53
      print_address_description+0x73/0x250 mm/kasan/report.c:252
      kasan_report_error mm/kasan/report.c:351 [inline]
      kasan_report+0x25b/0x340 mm/kasan/report.c:409
      check_memory_region_inline mm/kasan/kasan.c:260 [inline]
      check_memory_region+0x137/0x190 mm/kasan/kasan.c:267
      memcpy+0x37/0x50 mm/kasan/kasan.c:303
      memcpy include/linux/string.h:341 [inline]
      sha3_update+0xdf/0x2e0 crypto/sha3_generic.c:161
      crypto_shash_update+0xcb/0x220 crypto/shash.c:109
      shash_finup_unaligned+0x2a/0x60 crypto/shash.c:151
      crypto_shash_finup+0xc4/0x120 crypto/shash.c:165
      hmac_finup+0x182/0x330 crypto/hmac.c:152
      crypto_shash_finup+0xc4/0x120 crypto/shash.c:165
      shash_digest_unaligned+0x9e/0xd0 crypto/shash.c:172
      crypto_shash_digest+0xc4/0x120 crypto/shash.c:186
      hmac_setkey+0x36a/0x690 crypto/hmac.c:66
      crypto_shash_setkey+0xad/0x190 crypto/shash.c:64
      shash_async_setkey+0x47/0x60 crypto/shash.c:207
      crypto_ahash_setkey+0xaf/0x180 crypto/ahash.c:200
      hash_setkey+0x40/0x90 crypto/algif_hash.c:446
      alg_setkey crypto/af_alg.c:221 [inline]
      alg_setsockopt+0x2a1/0x350 crypto/af_alg.c:254
      SYSC_setsockopt net/socket.c:1851 [inline]
      SyS_setsockopt+0x189/0x360 net/socket.c:1830
      entry_SYSCALL_64_fastpath+0x1f/0x96

Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
[sw0312.kim: cherry-pick from linux-3.16.y to fix CVE-2017-17806]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: Icd8869c4d7ec660a97a83b5b957b72344e52b9c0

udp: consistently apply ufo or fragmentation

commit 85f1bd9a7b5a79d5baa8bf44af19658f7bf77bfa upstream.

When iteratively building a UDP datagram with MSG_MORE and that
datagram exceeds MTU, consistently choose UFO or fragmentation.

Once skb_is_gso, always apply ufo. Conversely, once a datagram is
split across multiple skbs, do not consider ufo.

Sendpage already maintains the first invariant, only add the second.
IPv6 does not have a sendpage implementation to modify.

A gso skb must have a partial checksum, do not follow sk_no_check_tx
in udp_send_skb.

Found by syzkaller.

[gregkh - tweaks for 3.18 for ipv6, hopefully they are correct...]
[wt: s/skb_is_gso/skb_has_frags for 3.10]

Fixes: e89e9cf539a2 ("[IPv4/IPv6]: UFO Scatter-gather approach")
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
[sw0312.kim: cherry-pick from linux-3.10.y to fix CVE-2017-1000112]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I1c077ccd10cc5009cd098f7cd931a850717f3297

udp: only allow UFO for packets from SOCK_DGRAM sockets

[ Upstream commit acf8dd0a9d0b9e4cdb597c2f74802f79c699e802 ]

If an over-MTU UDP datagram is sent through a SOCK_RAW socket to a
UFO-capable device, ip_ufo_append_data() sets skb->ip_summed to
CHECKSUM_PARTIAL unconditionally as all GSO code assumes transport layer
checksum is to be computed on segmentation. However, in this case,
skb->csum_start and skb->csum_offset are never set as raw socket
transmit path bypasses udp_send_skb() where they are usually set. As a
result, driver may access invalid memory when trying to calculate the
checksum and store the result (as observed in virtio_net driver).

Moreover, the very idea of modifying the userspace provided UDP header
is IMHO against raw socket semantics (I wasn't able to find a document
clearly stating this or the opposite, though). And while allowing
CHECKSUM_NONE in the UFO case would be more efficient, it would be a bit
too intrusive change just to handle a corner case like this. Therefore
disallowing UFO for packets from SOCK_DGRAM seems to be the best option.

Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[sw0312.kim: cherry-pick from linux-3.10.y to apply CVE patch]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: Ie0707eb6445f53af54a750c667a3b9f2bb5efa77

kernel/signal.c: avoid undefined behaviour in kill_something_info

When running kill(72057458746458112, 0) in userspace I hit the following
issue.

  UBSAN: Undefined behaviour in kernel/signal.c:1462:11
  negation of -2147483648 cannot be represented in type 'int':
  CPU: 226 PID: 9849 Comm: test Tainted: G    B          ---- -------   3.10.0-327.53.58.70.x86_64_ubsan+ #116
  Hardware name: Huawei Technologies Co., Ltd. RH8100 V3/BC61PBIA, BIOS BLHSV028 11/11/2014
  Call Trace:
    dump_stack+0x19/0x1b
    ubsan_epilogue+0xd/0x50
    __ubsan_handle_negate_overflow+0x109/0x14e
    SYSC_kill+0x43e/0x4d0
    SyS_kill+0xe/0x10
    system_call_fastpath+0x16/0x1b

Add code to avoid the UBSAN detection.

[akpm@linux-foundation.org: tweak comment]
Link: http://lkml.kernel.org/r/1496670008-59084-1-git-send-email-zhongjiang@huawei.com
Signed-off-by: zhongjiang <zhongjiang@huawei.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Xishi Qiu <qiuxishi@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[sw0312.kim: cherry-pick from mainline to fix CVE-2018-10124]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: Iaef10c2609a3e5bf23f3e4475bc24996884091a7

tcp: enable sockets to use MSG_FASTOPEN by default

Applications have started to use Fast Open (e.g., Chrome browser has
such an optional flag) and the feature has gone through several
generations of kernels since 3.7 with many real network tests. It's
time to enable this flag by default for applications to test more
conveniently and extensively.

Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Cheoleun Moon <chleun.moon@samsung.com>
[jh80.chung: cherry picked from commit 0d41cca490c2 from mainline]

Change-Id: I9dc9ce6e3e8de16bbefd5fd8c79ce9e4b39c4e81

ARM: tizen_tm1_defconfig: enable NETFILTER_XT_TARGET_LOG

Enable NETFILTER_XT_TARGET_LOG for analysis of iptables log.
It is a iptables feature for security report on Tizen 5.0,
required from stc-manager.

Signed-off-by: hyunuktak <hyunuk.tak@samsung.com>
Change-Id: Ia31c1e9463f28b74a67bad7272e0fea08c88c28c

ARM: tizen_tm1_defconfig: enable AUDITSYSCALL

Enabled AUDITSYSCALL for the use of audit subsystem.
A new security feature for Tizen 5.0 requires the subsystem
in default.

Change-Id: I4112a5ed4c6d232b77d0ba19f440cfdf4884249d
Signed-off-by: Inki Dae <inki.dae@samsung.com>

netfilter: nfnetlink_queue: fix secctx memory leak

We must call security_release_secctx to free the memory returned by
security_secid_to_secctx, otherwise memory may be leaked forever.

Fixes: ef493bd930ae ("netfilter: nfnetlink_queue: add security context information")
Signed-off-by: Liping Zhang <zlpnobody@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
[sw0312.kim: cherry-pick the commit 77c1c03c5b8 from mainline to fix already backported commit
- the commit ef493bd930ae ("netfilter: nfnetlink_queue: add security context information") was backported for nether.service in tizen
- change in net/netfilter/nfnetlink_queue.c is applied to net/netfilter/nfnetlink_queue_core.c]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: Ifbc5f96bb6039503b7390864936fe6eda2e53acb

proc, coredump: add CoreDumping flag to /proc/pid/status

Right now there is no convenient way to check if a process is being
coredumped at the moment.

It might be necessary to recognize such state to prevent killing the
process and getting a broken coredump.  Writing a large core might take
significant time, and the process is unresponsive during it, so it might
be killed by timeout, if another process is monitoring and
killing/restarting hanging tasks.

We're getting a significant number of corrupted coredump files on
machines in our fleet, just because processes are being killed by
timeout in the middle of the core writing process.

We do have a process health check, and some agent is responsible for
restarting processes which are not responding for health check requests.
Writing a large coredump to the disk can easily exceed the reasonable
timeout (especially on an overloaded machine).

This flag will allow the agent to distinguish processes which are being
coredumped, extend the timeout for them, and let them produce a full
coredump file.

To provide an ability to detect if a process is in the state of being
coredumped, we can expose a boolean CoreDumping flag in
/proc/pid/status.

Example:
$ cat core.sh
  #!/bin/sh

  echo "|/usr/bin/sleep 10" > /proc/sys/kernel/core_pattern
  sleep 1000 &
  PID=$!

  cat /proc/$PID/status | grep CoreDumping
  kill -ABRT $PID
  sleep 1
  cat /proc/$PID/status | grep CoreDumping

$ ./core.sh
  CoreDumping: 0
  CoreDumping: 1

[guro@fb.com: document CoreDumping flag in /proc/<pid>/status]
Link: http://lkml.kernel.org/r/20170928135357.GA8470@castle.DHCP.thefacebook.com
Link: http://lkml.kernel.org/r/20170920230634.31572-1-guro@fb.com
Signed-off-by: Roman Gushchin <guro@fb.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Konstantin Khlebnikov <koct9i@gmail.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[inki.dae: backported from mainline - commit : c643401218be
  On Tizen, there is one issue that a process doing coredump can be killed.
  This patch allows a process to detect if given process is being dumped.
  With this, Tizen can exclude such process from 'kill list' so that
  coredump process can finish coredump work.]
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Change-Id: Idf983ff897d0cea308372b1cc401b2a39388799f

misc: sdiodev: fix the wrong pointer type

Fix the wrong pointer type.

Change-Id: Id158d9e4128ea251a79644f62b4a6cf3146d162f
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>

misc: sim_slot: fix wrong fops callback

The write fops callback is assigned seq_lseek, but it is for llseek
callback. Also simslot_count never allows writing on it. Fix wrong
write fops callback to llseek callback.

Note: simslot_count is olny read by tel-plugin package and there is
no write or no lseek cases.

Change-Id: I0fe20e4caac899036bcdc5f01786bceaab059490
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

ARM: tizen_tm1_defconfig: disable FRAME_WARN config option

The CONFIG_FRAME_WARN sets size of frame stack to warn and there
are some build warnins caused by too large frame size. Disable
the warnings with setting CONFIG_FRAME_WARN as 0.

NOTE: it only disables warning but it does not mean large frame
size is acceptable.

Change-Id: I42d4fb948110b22495f8b57c391456a0bddc7db2
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

misc: sdio: remove build warnings

Remove build warnings.

Change-Id: I0b4506532ecce3e92d559f67903acf9cd250bc6e
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

mmc: core: remove build warning caused by sprd bsp

During sprd bsp, not used function is added and it causes unused
function build warning. Remove the build warning by removing the
function.

Change-Id: Id3cea904edca1c41413c28f0c831617b5385af25
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

mmc: sprd : remove build warnings

Remove build warnings including unused-variable, unused-label and
int-conversion.

Change-Id: I171d21f8fada70b27291730444ae82a5883fff0c
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

misc: mdbg: remove build warnings

Remove build warnings in sprd mdbg misc driver.

Change-Id: Ic2a06079da18f04252eeea8005e2ec6088de5c6a
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

misc: sprd: remove build warnings

Remove build warnings in sprd misc drivers.

Change-Id: I6d307506a956cbae56841f50a39f8fc59bc9c21e
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

regulator: core: remove build warning caused by sprd bsp

From sprd bsp, regulator_init_complete() is fixed not to be called
and it causes unused function build waring. Remove the build warning.

Change-Id: I63d26fbe9b22d4bb4467f859d2ad762998be0931
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

ion/sprd: remove build warning

Remove unused variable build warning.

Change-Id: Id630226984ac3eb379a973be5a42448f2da90cf8
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

base: sync: Include seq_file.h in sync.h

sync.h uses struct seq_file in some function table prototypes. This
causes compile failures when including the header in files that do not
otherwise include seq_file.h

Signed-off-by: Jonathan Hamilton <jonathan.hamilton@imgtec.com>
[sw0312.kim: cherry-pick the commit d37806bb7617 from https://android.googlesource.com/kernel/common to fix build warning]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I42183b09a64e26d57c5f176757f691378ffd578e

thermal: sprd: remove build warnings

Remove build warnings including unused-function, unused-variable,
incompatible-pointer-types and int-conversion.

Change-Id: Iae52665eb828e1b958c0a34970a2b3152b0699eb
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

serial: sprd: remove build warning

Remove build warnings including unused variable, unused function
and implicit pointer use from integer.

Change-Id: I9d2326cedfaeadd4de23d6fcd7a4d6d133ffdaac
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

backlight: ktd3102: remove build warnings

Remove build warnings caused from unused variable and non declared
struct.

Change-Id: I28b7cbd9cf166122583ce98f27769851bb85c12b
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

media: sprd_isp: remove build warnings

Remove build warnings including wrong print format, unused function,
and unused variable.

Change-Id: I21b97f3b98c9039126038c075ddb36ceaea09200
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

platform/sprd: remove build warnings

Remove build warnings from sprd platform drivers.

Change-Id: Ifd838abc5d012a908e94fdeec0ec320667a7e9d5
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

media: sprd_dcam: remove build warnings

Remove build warnings.

Change-Id: Iecca7b0767d47abb01e444b9a34d861917e5e149
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

fbdev: sprd: fix wrong sscanf() parameters

There were several wrong sscanf() parameter usages. Fix the wrong
parameters.

Note: "%s" format for sscanf() of kernel is required char * but it
was assigned char **, but strangely, both cases are fine on runtime.

Change-Id: I9c77a71f7c26fe25935c2633a5806291c537d181
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

fbdev: sprd: remove build warnings

Remove build warnings.

Change-Id: I6755843fe76058c42811fbbbf86d38e8dae9aaf3
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

media: sprd_sensor: fix wrong parameter on device_destroy()

There are wrong parameter usages for device_destroy() in error path. Fix
the wrong parameter with proper dev->devt element.

Change-Id: I4df6a5a1fefe9cd6884b9b1ef220648e1176587e
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

media: sprd_sensor: remove build warnings

Remoev build warnings.

Change-Id: I7ed9a94c98f99a82349cad38263c56375fbc1b44
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

iommu: sprd: remove build warnings

Remove build warnings including wrong casting, shift warning and
unused variable.

Change-Id: I8c9517725db3c59e0a3f5380543ae0aca93fda57
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

gpio/sprd-eic: remove build warning

Remove build warning because of no return check.

Change-Id: Idd46626118be4c76a22ecdd3cdb69e40cb549242
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

sprd/sipc: fix wrong double pointer usage

There is wrong converting double pointer to pointer. Fix the wrong
double pointer usage.

NOTE: sipc is built-in module, so the remove callback is not really
called and this does not really change operation flow.

Change-Id: I5f035c9e12003fdd1d0799f712fd6b450e101124
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

sprd/sipc: remove build warnings

Remove build warnings including wrong printing format and wrong cast.

Change-Id: If3ba9d58eab7bfa6a269934aedf1ba700692aafd
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

sprd/iq: remove build warning

Remove unused variable build warning.

Change-Id: I29c0b76b872c3f075c0493231aa6ad03920126cc
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

power: fuel_gauge: sprd2713: remove build warning

Remove wrong print format build warning.

Change-Id: I88964cebce54476dfc2baaa4f41085ae4fc90a6f
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

ARM: mach-sc: remove cast to pointer from integer of different size

Remove build warnings from cast to pointer from integer of different size.

Change-Id: I8ac8ec85f07df647b850a12e0bf54e81e6fe66ec
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>