profile/wearable/platform/kernel/linux-4.9-exynos9110.git
3 years agoarm64: config: tw3: enable CONFIG_SND_ALOOP 34/257134/3 accepted/tizen/unified/20210421.101136 submit/tizen/20210421.055007
Jaechul Lee [Tue, 20 Apr 2021 01:49:41 +0000 (10:49 +0900)]
arm64: config: tw3: enable CONFIG_SND_ALOOP

Enable CONFIG_SND_ALOOP for supporting Acoustic Echo Cancellation

Change-Id: Ib64a9209c9eaf746f6dd9b198f3330779ba08293
Signed-off-by: Jaechul Lee <jcsing.lee@samsung.com>
3 years agoALSA: aloop: Add 'PCM Master Active' control 33/257133/2
Jaechul Lee [Tue, 20 Apr 2021 01:41:09 +0000 (10:41 +0900)]
ALSA: aloop: Add 'PCM Master Active' control

Acoustic Echo Cancellation that is a tizen feature needs to know the
master active status to fall into a sleep when it doesn't need to
process any pcm data. 'PCM Master Active' control was added and
separated with 'PCM Slave Active' control. It will be notified to the
userspace when a user started to capture from aloop devices.

Change-Id: I4382c51dc30801b97d6a6d43e1ab36e0fa797393
Signed-off-by: Jaechul Lee <jcsing.lee@samsung.com>
3 years agodrm: vblank: Revert back to wait requested vblank sequence 42/257142/1 accepted/tizen/unified/20210420.090053 submit/tizen/20210420.053930
Seung-Woo Kim [Tue, 20 Apr 2021 04:01:48 +0000 (13:01 +0900)]
drm: vblank: Revert back to wait requested vblank sequence

For DRM_IOCTL_WAIT_VBLANK with event flag, waiting requested
sequence routine was removed, so it always sends vblank
event after exact one vblank. Revert back to wait requested
vblank sequence.

Change-Id: If335cafde04fe699ed3d81f0d3f994e91244a5e4
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
3 years agoARM64: defconfig: disable SECURITY_SMACK_NETFILTER config 12/253712/1 accepted/tizen/unified/20210217.120530 submit/tizen/20210217.042922
Jaehoon Chung [Wed, 17 Feb 2021 01:08:55 +0000 (10:08 +0900)]
ARM64: defconfig: disable SECURITY_SMACK_NETFILTER config

Disable SECURITY_SMACK_NETFILTER configuration.

Change-Id: I8b7260e54ad14770c9f64d05c75e84b9dc8fea34
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
3 years agoARM64: tizen_tw3_defconfig: enable a config prefech_128 for dm-verity 06/242206/2 accepted/tizen_6.0_unified accepted/tizen_6.0_unified_hotfix tizen_6.0 tizen_6.0_hotfix accepted/tizen/6.0/unified/20201030.102849 accepted/tizen/6.0/unified/hotfix/20201103.045018 accepted/tizen/unified/20200826.133047 submit/tizen/20200825.081721 submit/tizen_6.0/20201029.205505 submit/tizen_6.0_hotfix/20201102.192906 submit/tizen_6.0_hotfix/20201103.115106 tizen_6.0.m2_release
Jaehoon Chung [Tue, 25 Aug 2020 03:49:06 +0000 (12:49 +0900)]
ARM64: tizen_tw3_defconfig: enable a config prefech_128 for dm-verity

Enable CONFIG_DM_VEIRTY_HASH_PREFETCH_MIN_SIZE_128.

Change-Id: I2b8f8c8aa91f9e50429c7f5d76f9a2973973e6df
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
3 years agomd: dm-verity-target: change prefetch size to 128 if config is enabled 05/242205/2
Jaehoon Chung [Tue, 25 Aug 2020 03:48:58 +0000 (12:48 +0900)]
md: dm-verity-target: change prefetch size to 128 if config is enabled

If config is enabled, chagne prefetch size from 256 to 128.
It can be reduced the booting time about 10ms after enabling verity.
- With ignore_zero_blocks, it can be reduced about 100~120ms.
- it's dependent with storage, so it needs to check which value is best.

Change-Id: Id3ae01c143964fb3a41e66b407d20da410fa0441
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
3 years agoconfig: tw3: enable cpuset controller for cgroup 05/238405/3 accepted/tizen/unified/20200716.144554 submit/tizen/20200716.040454
Maciej Słodczyk [Mon, 13 Jul 2020 12:59:57 +0000 (14:59 +0200)]
config: tw3: enable cpuset controller for cgroup

Make cpuset interface available for resourced daemon
to control tizen apps' cpu distribution and scheduling.

Change-Id: I459334c5322c9fc661e25c87ba54ffb9f1748a0c
Signed-off-by: Maciej Słodczyk <m.slodczyk2@partner.samsung.com>
3 years agolib: zstd: huf_decompress: Cleanup code 20/237720/1
Dongwoo Lee [Fri, 3 Jul 2020 02:05:59 +0000 (11:05 +0900)]
lib: zstd: huf_decompress: Cleanup code

This fixes to explicitly initialize variable before use and removes
redundant assignment.

Change-Id: Id424707b886bf5dfb5473e2535d29adc46c9d92f
Suggested-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
4 years agolib: zstd: Improve decode performance 02/235402/3
Dongwoo Lee [Thu, 4 Jun 2020 04:54:44 +0000 (13:54 +0900)]
lib: zstd: Improve decode performance

To speed up decode performance, optimizations are brought from zstd
github repository and ported as kernel-style.

Since the low-level algorithm is preferred in linux due to
compression/decompression performance (default level 3), the
optimization for low-level is chosed as follows:

  [1] lib: zstd: Speed up single segment zstd_fast by 5%
      (https://github.com/facebook/zstd/pull/1562/commits/95624b77e477752b3c380c22be7bcf67f06c9934)
  [2] perf improvements for zstd decode
      (https://github.com/facebook/zstd/pull/1668/commits/29d1e81bbdfc21085529623e7bc5abcb3e1627ae)
  [3] updated double_fast complementary insertion
      (https://github.com/facebook/zstd/pull/1681/commits/d1327738c277643f09c972a407083ad73c8ecf7b)
  [4] Improvements in zstd decode performance
      (https://github.com/facebook/zstd/pull/1756/commits/b83059958246dfcb5b91af9c187fad8c706869a0)
  [5] Optimize decompression and fix wildcopy overread
      (https://github.com/facebook/zstd/pull/1804/commits/efd37a64eaff5a0a26ae2566fdb45dc4a0c91673)
  [6] Improve ZSTD_highbit32's codegen
      (https://github.com/facebook/zstd/commit/a07da7b0db682c170a330a8c21585be3d68275fa)
  [7] Optimize decompression speed for gcc and clang (#1892)
      (https://github.com/facebook/zstd/commit/718f00ff6fe42db7e6ba09a7f7992b3e85283f77)
  [8] Fix performance regression on aarch64 with clang
      (https://github.com/facebook/zstd/pull/1973/commits/cb2abc3dbe010113d9e00ca3b612bf61983145a2)

Change-Id: I4f7bdba934383d2a5370e8da1ebf4314e0867d3e
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
4 years agoblock: zram: Add support for dynamic compressor switch 04/235304/4
Dongwoo Lee [Thu, 4 Jun 2020 04:54:35 +0000 (13:54 +0900)]
block: zram: Add support for dynamic compressor switch

Orginally, the compression algorithm cannot be changed until
resetting it if zram is once initialized by setting disksize. Since
this, however, zram can have multiple compressor and switch them
dynamically.

With this, zram uses the algorithm which is fast but has low
compression ratio at first, and can change to the one that is slightly
slower but having higher ratio when the target get bothered by low
memory.

Change-Id: Icf9ac074b340122532a10d4e28fd0c182dbcc8a9
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
4 years agozram: add zstd to the supported algorithms list 31/235231/3
Sergey Senozhatsky [Thu, 16 Nov 2017 01:33:49 +0000 (17:33 -0800)]
zram: add zstd to the supported algorithms list

Add ZSTD to the list of supported compression algorithms.

ZRAM fio perf test:

                      LZO         DEFLATE         ZSTD

WRITE:              (2180MB/s)   (77.2MB/s)      (1429MB/s)
WRITE:              (1617MB/s)   (77.7MB/s)      (1202MB/s)
READ:                (426MB/s)   (595MB/s)       (1181MB/s)
READ:                (422MB/s)   (572MB/s)       (1020MB/s)
READ:                (318MB/s)   (67.8MB/s)      (563MB/s)
WRITE:               (318MB/s)   (67.9MB/s)      (564MB/s)
READ:                (336MB/s)   (68.3MB/s)      (583MB/s)
WRITE:               (335MB/s)   (68.2MB/s)      (582MB/s)
WRITE:              (3441MB/s)   (152MB/s)       (2141MB/s)
WRITE:              (2507MB/s)   (147MB/s)       (1888MB/s)
READ:                (801MB/s)   (1146MB/s)      (1890MB/s)
READ:                (767MB/s)   (1096MB/s)      (2073MB/s)
READ:                (621MB/s)   (126MB/s)       (1009MB/s)
WRITE:               (621MB/s)   (126MB/s)       (1009MB/s)
READ:                (656MB/s)   (125MB/s)       (1075MB/s)
WRITE:               (657MB/s)   (126MB/s)       (1077MB/s)
WRITE:              (4772MB/s)   (225MB/s)       (3394MB/s)
WRITE:              (3905MB/s)   (211MB/s)       (2939MB/s)
READ:               (1216MB/s)   (1608MB/s)      (3218MB/s)
READ:               (1159MB/s)   (1431MB/s)      (2981MB/s)
READ:                (906MB/s)   (156MB/s)       (1457MB/s)
WRITE:               (907MB/s)   (156MB/s)       (1458MB/s)
READ:                (953MB/s)   (158MB/s)       (1595MB/s)
WRITE:               (952MB/s)   (157MB/s)       (1593MB/s)
WRITE:              (6036MB/s)   (265MB/s)       (4469MB/s)
WRITE:              (5059MB/s)   (263MB/s)       (3951MB/s)
READ:               (1618MB/s)   (2066MB/s)      (4276MB/s)
READ:               (1573MB/s)   (1942MB/s)      (3830MB/s)
READ:               (1202MB/s)   (227MB/s)       (1971MB/s)
WRITE:              (1200MB/s)   (227MB/s)       (1968MB/s)
READ:               (1265MB/s)   (226MB/s)       (2116MB/s)
WRITE:              (1264MB/s)   (226MB/s)       (2114MB/s)
WRITE:              (5339MB/s)   (233MB/s)       (3781MB/s)
WRITE:              (4298MB/s)   (234MB/s)       (3276MB/s)
READ:               (1626MB/s)   (2048MB/s)      (4081MB/s)
READ:               (1567MB/s)   (1929MB/s)      (3758MB/s)
READ:               (1174MB/s)   (205MB/s)       (1747MB/s)
WRITE:              (1173MB/s)   (204MB/s)       (1746MB/s)
READ:               (1214MB/s)   (208MB/s)       (1890MB/s)
WRITE:              (1215MB/s)   (208MB/s)       (1892MB/s)
WRITE:              (5666MB/s)   (270MB/s)       (4338MB/s)
WRITE:              (4828MB/s)   (267MB/s)       (3772MB/s)
READ:               (1803MB/s)   (2058MB/s)      (4946MB/s)
READ:               (1805MB/s)   (2156MB/s)      (4711MB/s)
READ:               (1334MB/s)   (235MB/s)       (2135MB/s)
WRITE:              (1335MB/s)   (235MB/s)       (2137MB/s)
READ:               (1364MB/s)   (236MB/s)       (2268MB/s)
WRITE:              (1365MB/s)   (237MB/s)       (2270MB/s)
WRITE:              (5474MB/s)   (270MB/s)       (4300MB/s)
WRITE:              (4666MB/s)   (266MB/s)       (3817MB/s)
READ:               (2022MB/s)   (2319MB/s)      (5472MB/s)
READ:               (1924MB/s)   (2260MB/s)      (5031MB/s)
READ:               (1369MB/s)   (242MB/s)       (2153MB/s)
WRITE:              (1370MB/s)   (242MB/s)       (2155MB/s)
READ:               (1499MB/s)   (246MB/s)       (2310MB/s)
WRITE:              (1497MB/s)   (246MB/s)       (2307MB/s)
WRITE:              (5558MB/s)   (273MB/s)       (4439MB/s)
WRITE:              (4763MB/s)   (271MB/s)       (3918MB/s)
READ:               (2201MB/s)   (2599MB/s)      (6062MB/s)
READ:               (2105MB/s)   (2463MB/s)      (5413MB/s)
READ:               (1490MB/s)   (252MB/s)       (2238MB/s)
WRITE:              (1488MB/s)   (252MB/s)       (2236MB/s)
READ:               (1566MB/s)   (254MB/s)       (2434MB/s)
WRITE:              (1568MB/s)   (254MB/s)       (2437MB/s)
WRITE:              (5120MB/s)   (264MB/s)       (4035MB/s)
WRITE:              (4531MB/s)   (267MB/s)       (3740MB/s)
READ:               (1940MB/s)   (2258MB/s)      (4986MB/s)
READ:               (2024MB/s)   (2387MB/s)      (4871MB/s)
READ:               (1343MB/s)   (246MB/s)       (2038MB/s)
WRITE:              (1342MB/s)   (246MB/s)       (2037MB/s)
READ:               (1553MB/s)   (238MB/s)       (2243MB/s)
WRITE:              (1552MB/s)   (238MB/s)       (2242MB/s)
WRITE:              (5345MB/s)   (271MB/s)       (3988MB/s)
WRITE:              (4750MB/s)   (254MB/s)       (3668MB/s)
READ:               (1876MB/s)   (2363MB/s)      (5150MB/s)
READ:               (1990MB/s)   (2256MB/s)      (5080MB/s)
READ:               (1355MB/s)   (250MB/s)       (2019MB/s)
WRITE:              (1356MB/s)   (251MB/s)       (2020MB/s)
READ:               (1490MB/s)   (252MB/s)       (2202MB/s)
WRITE:              (1488MB/s)   (252MB/s)       (2199MB/s)

jobs1                              perfstat
instructions                 52,065,555,710 (    0.79)    855,731,114,587 (    2.64)       54,280,709,944 (    1.40)
branches                     14,020,427,116 ( 725.847)    101,733,449,582 (1074.521)       11,170,591,067 ( 992.869)
branch-misses                    22,626,174 (   0.16%)        274,197,885 (   0.27%)           25,915,805 (   0.23%)
jobs2                              perfstat
instructions                103,633,110,402 (    0.75)  1,710,822,100,914 (    2.59)      107,879,874,104 (    1.28)
branches                     27,931,237,282 ( 679.203)    203,298,267,479 (1037.326)       22,185,350,842 ( 884.427)
branch-misses                    46,103,811 (   0.17%)        533,747,204 (   0.26%)           49,682,483 (   0.22%)
jobs3                              perfstat
instructions                154,857,283,657 (    0.76)  2,565,748,974,197 (    2.57)      161,515,435,813 (    1.31)
branches                     41,759,490,355 ( 670.529)    304,905,605,277 ( 978.765)       33,215,805,907 ( 888.003)
branch-misses                    74,263,293 (   0.18%)        759,746,240 (   0.25%)           76,841,196 (   0.23%)
jobs4                              perfstat
instructions                206,215,849,076 (    0.75)  3,420,169,460,897 (    2.60)      215,003,061,664 (    1.31)
branches                     55,632,141,739 ( 666.501)    406,394,977,433 ( 927.241)       44,214,322,251 ( 883.532)
branch-misses                   102,287,788 (   0.18%)      1,098,617,314 (   0.27%)          103,891,040 (   0.23%)
jobs5                              perfstat
instructions                258,711,315,588 (    0.67)  4,275,657,533,244 (    2.23)      269,332,235,685 (    1.08)
branches                     69,802,821,166 ( 588.823)    507,996,211,252 ( 797.036)       55,450,846,129 ( 735.095)
branch-misses                   129,217,214 (   0.19%)      1,243,284,991 (   0.24%)          173,512,278 (   0.31%)
jobs6                              perfstat
instructions                312,796,166,008 (    0.61)  5,133,896,344,660 (    2.02)      323,658,769,588 (    1.04)
branches                     84,372,488,583 ( 520.541)    610,310,494,402 ( 697.642)       66,683,292,992 ( 693.939)
branch-misses                   159,438,978 (   0.19%)      1,396,368,563 (   0.23%)          174,406,934 (   0.26%)
jobs7                              perfstat
instructions                363,211,372,930 (    0.56)  5,988,205,600,879 (    1.75)      377,824,674,156 (    0.93)
branches                     98,057,013,765 ( 463.117)    711,841,255,974 ( 598.762)       77,879,009,954 ( 600.443)
branch-misses                   199,513,153 (   0.20%)      1,507,651,077 (   0.21%)          248,203,369 (   0.32%)
jobs8                              perfstat
instructions                413,960,354,615 (    0.52)  6,842,918,558,378 (    1.45)      431,938,486,581 (    0.83)
branches                    111,812,574,884 ( 414.224)    813,299,084,518 ( 491.173)       89,062,699,827 ( 517.795)
branch-misses                   233,584,845 (   0.21%)      1,531,593,921 (   0.19%)          286,818,489 (   0.32%)
jobs9                              perfstat
instructions                465,976,220,300 (    0.53)  7,698,467,237,372 (    1.47)      486,352,600,321 (    0.84)
branches                    125,931,456,162 ( 424.063)    915,207,005,715 ( 498.192)      100,370,404,090 ( 517.439)
branch-misses                   256,992,445 (   0.20%)      1,782,809,816 (   0.19%)          345,239,380 (   0.34%)
jobs10                             perfstat
instructions                517,406,372,715 (    0.53)  8,553,527,312,900 (    1.48)      540,732,653,094 (    0.84)
branches                    139,839,780,676 ( 427.732)  1,016,737,699,389 ( 503.172)      111,696,557,638 ( 516.750)
branch-misses                   259,595,561 (   0.19%)      1,952,570,279 (   0.19%)          357,818,661 (   0.32%)

seconds elapsed        20.630411534     96.084546565    12.743373571
seconds elapsed        22.292627625     100.984155001   14.407413560
seconds elapsed        22.396016966     110.344880848   14.032201392
seconds elapsed        22.517330949     113.351459170   14.243074935
seconds elapsed        28.548305104     156.515193765   19.159286861
seconds elapsed        30.453538116     164.559937678   19.362492717
seconds elapsed        33.467108086     188.486827481   21.492612173
seconds elapsed        35.617727591     209.602677783   23.256422492
seconds elapsed        42.584239509     243.959902566   28.458540338
seconds elapsed        47.683632526     269.635248851   31.542404137

Over all, ZSTD has slower WRITE, but much faster READ (perhaps
a static compression buffer used during the test helped ZSTD a
lot), which results in faster test results.

Memory consumption (zram mm_stat file):

zram LZO mm_stat
mm_stat (jobs1): 2147483648 23068672 33558528        0 33558528        0        0
mm_stat (jobs2): 2147483648 23068672 33558528        0 33558528        0        0
mm_stat (jobs3): 2147483648 23068672 33558528        0 33562624        0        0
mm_stat (jobs4): 2147483648 23068672 33558528        0 33558528        0        0
mm_stat (jobs5): 2147483648 23068672 33558528        0 33558528        0        0
mm_stat (jobs6): 2147483648 23068672 33558528        0 33562624        0        0
mm_stat (jobs7): 2147483648 23068672 33558528        0 33566720        0        0
mm_stat (jobs8): 2147483648 23068672 33558528        0 33558528        0        0
mm_stat (jobs9): 2147483648 23068672 33558528        0 33558528        0        0
mm_stat (jobs10): 2147483648 23068672 33558528        0 33562624        0        0

zram DEFLATE mm_stat
mm_stat (jobs1): 2147483648 16252928 25178112        0 25178112        0        0
mm_stat (jobs2): 2147483648 16252928 25178112        0 25178112        0        0
mm_stat (jobs3): 2147483648 16252928 25178112        0 25178112        0        0
mm_stat (jobs4): 2147483648 16252928 25178112        0 25178112        0        0
mm_stat (jobs5): 2147483648 16252928 25178112        0 25178112        0        0
mm_stat (jobs6): 2147483648 16252928 25178112        0 25178112        0        0
mm_stat (jobs7): 2147483648 16252928 25178112        0 25190400        0        0
mm_stat (jobs8): 2147483648 16252928 25178112        0 25190400        0        0
mm_stat (jobs9): 2147483648 16252928 25178112        0 25178112        0        0
mm_stat (jobs10): 2147483648 16252928 25178112        0 25178112        0        0

zram ZSTD mm_stat
mm_stat (jobs1): 2147483648 11010048 16781312        0 16781312        0        0
mm_stat (jobs2): 2147483648 11010048 16781312        0 16781312        0        0
mm_stat (jobs3): 2147483648 11010048 16781312        0 16785408        0        0
mm_stat (jobs4): 2147483648 11010048 16781312        0 16781312        0        0
mm_stat (jobs5): 2147483648 11010048 16781312        0 16781312        0        0
mm_stat (jobs6): 2147483648 11010048 16781312        0 16781312        0        0
mm_stat (jobs7): 2147483648 11010048 16781312        0 16781312        0        0
mm_stat (jobs8): 2147483648 11010048 16781312        0 16781312        0        0
mm_stat (jobs9): 2147483648 11010048 16781312        0 16785408        0        0
mm_stat (jobs10): 2147483648 11010048 16781312        0 16781312        0        0

==================================================================================

Official benchmarks [1]:

Compressor name         Ratio   Compression     Decompress.
zstd 1.1.3 -1           2.877   430 MB/s        1110 MB/s
zlib 1.2.8 -1           2.743   110 MB/s        400 MB/s
brotli 0.5.2 -0         2.708   400 MB/s        430 MB/s
quicklz 1.5.0 -1        2.238   550 MB/s        710 MB/s
lzo1x 2.09 -1           2.108   650 MB/s        830 MB/s
lz4 1.7.5               2.101   720 MB/s        3600 MB/s
snappy 1.1.3            2.091   500 MB/s        1650 MB/s
lzf 3.6 -1              2.077   400 MB/s        860 MB/s

Minchan said:

: I did test with my sample data and compared zstd with deflate.  zstd's
: compress ratio is lower a little bit but compression speed is much faster
: 3 times more and decompress speed is too 2 times more.  With different
: data, it is different but overall, zstd would be better for speed at the
: cost of a little lower compress ratio(about 5%) so I believe it's worth to
: replace deflate.

[1] https://github.com/facebook/zstd

Link: http://lkml.kernel.org/r/20170912050005.3247-1-sergey.senozhatsky@gmail.com
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Tested-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[dwoo08.lee: backport upstream commit 5ef3a8b12556d to add zstd to zram compressor]
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
Change-Id: If4e2d781e5540300a57f9a93ef77360bd1c32e85

4 years agoarm64: tizen_tw3_defconfig: Enable ZSTD crypto 30/235230/2
Dongwoo Lee [Wed, 3 Jun 2020 02:07:09 +0000 (11:07 +0900)]
arm64: tizen_tw3_defconfig: Enable ZSTD crypto

This enables zstd crypto for tw3 to support it as zram compressor.

Change-Id: I5cf2bd6c0b016e53023764c2a297c741f23eda6e
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
4 years agocrypto: Add zstd support 29/235229/1
Nick Terrell [Thu, 3 Aug 2017 01:02:13 +0000 (18:02 -0700)]
crypto: Add zstd support

Adds zstd support to crypto and scompress. Only supports the default
level.

Previously we held off on this patch, since there weren't any users.
Now zram is ready for zstd support, but depends on CONFIG_CRYPTO_ZSTD,
which isn't defined until this patch is in. I also see a patch adding
zstd to pstore [0], which depends on crypto zstd.

[0] lkml.kernel.org/r/9c9416b2dff19f05fb4c35879aaa83d11ff72c92.1521626182.git.geliangtang@gmail.com

Signed-off-by: Nick Terrell <terrelln@fb.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
[dwoo08.lee: backport upstream commit d28fc3dbe191 for applying zstd to zram]
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
Change-Id: I27969ec0cda2a6f6280ef6a10ee5cc33938032d1

4 years agolib: Add zstd modules 28/235228/1
Nick Terrell [Tue, 18 Jul 2017 00:08:19 +0000 (17:08 -0700)]
lib: Add zstd modules

Add zstd compression and decompression kernel modules.
zstd offers a wide varity of compression speed and quality trade-offs.
It can compress at speeds approaching lz4, and quality approaching lzma.
zstd decompressions at speeds more than twice as fast as zlib, and
decompression speed remains roughly the same across all compression levels.

The code was ported from the upstream zstd source repository. The
`linux/zstd.h` header was modified to match linux kernel style.
The cross-platform and allocation code was stripped out. Instead zstd
requires the caller to pass a preallocated workspace. The source files
were clang-formatted [1] to match the Linux Kernel style as much as
possible. Otherwise, the code was unmodified. We would like to avoid
as much further manual modification to the source code as possible, so it
will be easier to keep the kernel zstd up to date.

I benchmarked zstd compression as a special character device. I ran zstd
and zlib compression at several levels, as well as performing no
compression, which measure the time spent copying the data to kernel space.
Data is passed to the compresser 4096 B at a time. The benchmark file is
located in the upstream zstd source repository under
`contrib/linux-kernel/zstd_compress_test.c` [2].

I ran the benchmarks on a Ubuntu 14.04 VM with 2 cores and 4 GiB of RAM.
The VM is running on a MacBook Pro with a 3.1 GHz Intel Core i7 processor,
16 GB of RAM, and a SSD. I benchmarked using `silesia.tar` [3], which is
211,988,480 B large. Run the following commands for the benchmark:

    sudo modprobe zstd_compress_test
    sudo mknod zstd_compress_test c 245 0
    sudo cp silesia.tar zstd_compress_test

The time is reported by the time of the userland `cp`.
The MB/s is computed with

    1,536,217,008 B / time(buffer size, hash)

which includes the time to copy from userland.
The Adjusted MB/s is computed with

    1,536,217,088 B / (time(buffer size, hash) - time(buffer size, none)).

The memory reported is the amount of memory the compressor requests.

| Method   | Size (B) | Time (s) | Ratio | MB/s    | Adj MB/s | Mem (MB) |
|----------|----------|----------|-------|---------|----------|----------|
| none     | 11988480 |    0.100 |     1 | 2119.88 |        - |        - |
| zstd -1  | 73645762 |    1.044 | 2.878 |  203.05 |   224.56 |     1.23 |
| zstd -3  | 66988878 |    1.761 | 3.165 |  120.38 |   127.63 |     2.47 |
| zstd -5  | 65001259 |    2.563 | 3.261 |   82.71 |    86.07 |     2.86 |
| zstd -10 | 60165346 |   13.242 | 3.523 |   16.01 |    16.13 |    13.22 |
| zstd -15 | 58009756 |   47.601 | 3.654 |    4.45 |     4.46 |    21.61 |
| zstd -19 | 54014593 |  102.835 | 3.925 |    2.06 |     2.06 |    60.15 |
| zlib -1  | 77260026 |    2.895 | 2.744 |   73.23 |    75.85 |     0.27 |
| zlib -3  | 72972206 |    4.116 | 2.905 |   51.50 |    52.79 |     0.27 |
| zlib -6  | 68190360 |    9.633 | 3.109 |   22.01 |    22.24 |     0.27 |
| zlib -9  | 67613382 |   22.554 | 3.135 |    9.40 |     9.44 |     0.27 |

I benchmarked zstd decompression using the same method on the same machine.
The benchmark file is located in the upstream zstd repo under
`contrib/linux-kernel/zstd_decompress_test.c` [4]. The memory reported is
the amount of memory required to decompress data compressed with the given
compression level. If you know the maximum size of your input, you can
reduce the memory usage of decompression irrespective of the compression
level.

| Method   | Time (s) | MB/s    | Adjusted MB/s | Memory (MB) |
|----------|----------|---------|---------------|-------------|
| none     |    0.025 | 8479.54 |             - |           - |
| zstd -1  |    0.358 |  592.15 |        636.60 |        0.84 |
| zstd -3  |    0.396 |  535.32 |        571.40 |        1.46 |
| zstd -5  |    0.396 |  535.32 |        571.40 |        1.46 |
| zstd -10 |    0.374 |  566.81 |        607.42 |        2.51 |
| zstd -15 |    0.379 |  559.34 |        598.84 |        4.61 |
| zstd -19 |    0.412 |  514.54 |        547.77 |        8.80 |
| zlib -1  |    0.940 |  225.52 |        231.68 |        0.04 |
| zlib -3  |    0.883 |  240.08 |        247.07 |        0.04 |
| zlib -6  |    0.844 |  251.17 |        258.84 |        0.04 |
| zlib -9  |    0.837 |  253.27 |        287.64 |        0.04 |

Tested in userland using the test-suite in the zstd repo under
`contrib/linux-kernel/test/UserlandTest.cpp` [5] by mocking the kernel
functions. Fuzz tested using libfuzzer [6] with the fuzz harnesses under
`contrib/linux-kernel/test/{RoundTripCrash.c,DecompressCrash.c}` [7] [8]
with ASAN, UBSAN, and MSAN. Additionaly, it was tested while testing the
BtrFS and SquashFS patches coming next.

[1] https://clang.llvm.org/docs/ClangFormat.html
[2] https://github.com/facebook/zstd/blob/dev/contrib/linux-kernel/zstd_compress_test.c
[3] http://sun.aei.polsl.pl/~sdeor/index.php?page=silesia
[4] https://github.com/facebook/zstd/blob/dev/contrib/linux-kernel/zstd_decompress_test.c
[5] https://github.com/facebook/zstd/blob/dev/contrib/linux-kernel/test/UserlandTest.cpp
[6] http://llvm.org/docs/LibFuzzer.html
[7] https://github.com/facebook/zstd/blob/dev/contrib/linux-kernel/test/RoundTripCrash.c
[8] https://github.com/facebook/zstd/blob/dev/contrib/linux-kernel/test/DecompressCrash.c

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

Signed-off-by: Nick Terrell <terrelln@fb.com>
Signed-off-by: Chris Mason <clm@fb.com>
[dwoo08.lee: backport upstream commit 73f3d1b48f50]
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
Change-Id: I56d705828be2030b071b34d3eef4b7e56df98960

4 years agolib: Add xxhash module 27/235227/1
Nick Terrell [Tue, 18 Jul 2017 00:07:18 +0000 (17:07 -0700)]
lib: Add xxhash module

Adds xxhash kernel module with xxh32 and xxh64 hashes. xxhash is an
extremely fast non-cryptographic hash algorithm for checksumming.
The zstd compression and decompression modules added in the next patch
require xxhash. I extracted it out from zstd since it is useful on its
own. I copied the code from the upstream XXHash source repository and
translated it into kernel style. I ran benchmarks and tests in the kernel
and tests in userland.

I benchmarked xxhash as a special character device. I ran in four modes,
no-op, xxh32, xxh64, and crc32. The no-op mode simply copies the data to
kernel space and ignores it. The xxh32, xxh64, and crc32 modes compute
hashes on the copied data. I also ran it with four different buffer sizes.
The benchmark file is located in the upstream zstd source repository under
`contrib/linux-kernel/xxhash_test.c` [1].

I ran the benchmarks on a Ubuntu 14.04 VM with 2 cores and 4 GiB of RAM.
The VM is running on a MacBook Pro with a 3.1 GHz Intel Core i7 processor,
16 GB of RAM, and a SSD. I benchmarked using the file `filesystem.squashfs`
from `ubuntu-16.10-desktop-amd64.iso`, which is 1,536,217,088 B large.
Run the following commands for the benchmark:

    modprobe xxhash_test
    mknod xxhash_test c 245 0
    time cp filesystem.squashfs xxhash_test

The time is reported by the time of the userland `cp`.
The GB/s is computed with

    1,536,217,008 B / time(buffer size, hash)

which includes the time to copy from userland.
The Normalized GB/s is computed with

    1,536,217,088 B / (time(buffer size, hash) - time(buffer size, none)).

| Buffer Size (B) | Hash  | Time (s) | GB/s | Adjusted GB/s |
|-----------------|-------|----------|------|---------------|
|            1024 | none  |    0.408 | 3.77 |             - |
|            1024 | xxh32 |    0.649 | 2.37 |          6.37 |
|            1024 | xxh64 |    0.542 | 2.83 |         11.46 |
|            1024 | crc32 |    1.290 | 1.19 |          1.74 |
|            4096 | none  |    0.380 | 4.04 |             - |
|            4096 | xxh32 |    0.645 | 2.38 |          5.79 |
|            4096 | xxh64 |    0.500 | 3.07 |         12.80 |
|            4096 | crc32 |    1.168 | 1.32 |          1.95 |
|            8192 | none  |    0.351 | 4.38 |             - |
|            8192 | xxh32 |    0.614 | 2.50 |          5.84 |
|            8192 | xxh64 |    0.464 | 3.31 |         13.60 |
|            8192 | crc32 |    1.163 | 1.32 |          1.89 |
|           16384 | none  |    0.346 | 4.43 |             - |
|           16384 | xxh32 |    0.590 | 2.60 |          6.30 |
|           16384 | xxh64 |    0.466 | 3.30 |         12.80 |
|           16384 | crc32 |    1.183 | 1.30 |          1.84 |

Tested in userland using the test-suite in the zstd repo under
`contrib/linux-kernel/test/XXHashUserlandTest.cpp` [2] by mocking the
kernel functions. A line in each branch of every function in `xxhash.c`
was commented out to ensure that the test-suite fails. Additionally
tested while testing zstd and with SMHasher [3].

[1] https://phabricator.intern.facebook.com/P57526246
[2] https://github.com/facebook/zstd/blob/dev/contrib/linux-kernel/test/XXHashUserlandTest.cpp
[3] https://github.com/aappleby/smhasher

zstd source repository: https://github.com/facebook/zstd
XXHash source repository: https://github.com/cyan4973/xxhash

Signed-off-by: Nick Terrell <terrelln@fb.com>
Signed-off-by: Chris Mason <clm@fb.com>
[dwoo08.lee: backport from upstream commit 5d2405227a9e as base of zstd compaction library]
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
Change-Id: Id040bddd2c5661473ae16525453d17301e843d47

4 years agocrypto: acomp - add driver-side scomp interface 26/235226/1
Giovanni Cabiddu [Fri, 21 Oct 2016 12:19:48 +0000 (13:19 +0100)]
crypto: acomp - add driver-side scomp interface

Add a synchronous back-end (scomp) to acomp. This allows to easily
expose the already present compression algorithms in LKCF via acomp.

Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
[dwoo08.lee: backport from upstream commit 1ab53a77b772 to apply xxhash and zstd]
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
Change-Id: Ic67e525fc5463875898e89fcbca903e1cdb122e1

4 years agocrypto: acomp - add asynchronous compression api 25/235225/1
Giovanni Cabiddu [Fri, 21 Oct 2016 12:19:47 +0000 (13:19 +0100)]
crypto: acomp - add asynchronous compression api

Add acomp, an asynchronous compression api that uses scatterlist
buffers.

Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
[dwoo08.lee: backport from upstream commit 2ebda74fd6c9 to apply xxhash and zstd]
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
Change-Id: Iab8381411103a6b8e9a5b8d3c4d5fe30c6893002

4 years agoBluetooth: Add error handling logic of LE data batching 24/233624/3 accepted/tizen/unified/20200528.132937 submit/tizen/20200526.073613
Deokhyun Kim [Mon, 4 May 2020 08:18:11 +0000 (17:18 +0900)]
Bluetooth: Add error handling logic of LE data batching

Change-Id: Idb111d65552ef484cdf5a5f4d795d94a2c165db9
Signed-off-by: Deokhyun Kim <dukan.kim@samsung.com>
Signed-off-by: Wootak Jung <wootak.jung@samsung.com>
4 years agoarm64: dts: tw3: use array for motor strength and frequency setting for multiple... 17/232617/3
jeongsup.jeong [Fri, 24 Apr 2020 10:08:09 +0000 (19:08 +0900)]
arm64: dts: tw3: use array for motor strength and frequency setting for multiple level

Add new properties data to devicetree in order to support
the new motor parameters.

Change-Id: I9358562f51557d71b1ec06037637604377d46179
Signed-off-by: jeongsup.jeong <jeongsup.jeong@samsung.com>
[cw00.choi: Add commit-msg as the public style]
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
4 years agoMotor: use default frequency when platform frequency request is predefined value, 0 16/232616/3
jeongsup.jeong [Wed, 25 Mar 2020 10:30:57 +0000 (19:30 +0900)]
Motor: use default frequency when platform frequency request is predefined value, 0

Change the default value of frequency from 1 to 0 as following:
- 0 (Use default frequency)
- 1 ~ 8191 (0.1 ~ 819.1 Hz)

And check whether intensity_level is valid or in the early ztm620_motor_run()
function. The intensity_level should be less than count_strength and
count_frequency. The number of count_strength and count_frequency are fixed
according to the h/w device. Each h/w device specifies the number of
count_strength and count_frequency in their own devicetree.

Change-Id: Ia81cdcde06d670c916f32b5b105b5ade44dc016c
Signed-off-by: jeongsup.jeong <jeongsup.jeong@samsung.com>
[cw00.choi: Add commig-msg as the public style]
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
4 years agoMotor: change motor control parameters for new haptic concept 15/232615/3
jeongsup.jeong [Fri, 27 Dec 2019 06:09:50 +0000 (15:09 +0900)]
Motor: change motor control parameters for new haptic concept

Change the motor control parameters which are used for communicating
between feedbackd in user-space and motor device driver in kernel.

[Detailed motor control parameters]
struct ff_rumble_effect {
__u16 strong_magnitude; // strong_magnitude[15:15] = 0 (Reserved)
// strong_magnitude[14:14]
//   = Overdrive : 0 (Off) or 1 (On)
// strong_magnitude[13:0]
//   = Intensity Value : 0 (Stop)
//     or 1 ~ 10000 (Intensity)
__u16 weak_magnitude; // weak_magnitude[15:13]
//   = Intensity Level : 1 ~ 5
// weak_magnitude[12:0]
//   = Frequency in 0.1Hz : 0 ~ 8191 (0 ~ 819.1 Hz)
}; */

Change-Id: I3d65855086c2685ddaea3a494d2109f86a29cdbd
Signed-off-by: jeongsup.jeong <jeongsup.jeong@samsung.com>
[cw00.choi: Add commit-msg as the public style]
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
4 years agoMotor: add handling freq, overdrive param on ff effect 14/232614/3
jeongsup.jeong [Mon, 22 Jul 2019 09:39:34 +0000 (18:39 +0900)]
Motor: add handling freq, overdrive param on ff effect

In order to handle the motor behavior in details,
add new 'frequency' and 'overdrive' parameter for ff (force feedback) effect.

Use the existing 'struct ff_runbm_effect' without any added variable
to pass the user data to input device driver of kernel.

Change-Id: I3f1e7ed8b280bdbfdf50bab7299d0f2b67ad3914
Signed-off-by: jeongsup.jeong <jeongsup.jeong@samsung.com>
[cw00.choi: Add commit-msg as public style and fix the merge conflict]
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
4 years agoMotor: ztm620: add motor status interface 13/232613/3
jeongsup.jeong [Thu, 13 Jun 2019 04:36:32 +0000 (13:36 +0900)]
Motor: ztm620: add motor status interface

Add exported ztm620_motor_is_running() function to inform the motor state
to outside of ztm620 device driver.

Change-Id: If9e1b42755d0b2c7d8c1f10d78746be58d011b6b
Signed-off-by: jeongsup.jeong <jeongsup.jeong@samsung.com>
[cw00.choi: Add commit-msg as the public style]
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
4 years agomotor: ztm620: set dc motor dt and add switch motor type 12/232612/3
woochul.shin [Wed, 6 May 2020 09:56:00 +0000 (18:56 +0900)]
motor: ztm620: set dc motor dt and add switch motor type

Modify the motor data such as motor_start_data and motor_stop_dat
according to the motor type. Each h/w device is able to select
the their own motor type in devicetree.

Example of the motor type,
- TW3's motor type is LRA

Change-Id: I2d2f830ff787ab7a9d5f042a0a7ba139b4401258
Signed-off-by: woochul.shin <woochul.shin@samsung.com>
[cw00.choi: Add commig-msg as the public style]
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
4 years agoMotor: ztm620: add pm_notifier 11/232611/3
jeongsup.jeong [Tue, 20 Nov 2018 04:50:58 +0000 (13:50 +0900)]
Motor: ztm620: add pm_notifier

Add PM Notifier in order to control the state of motor device.
When PM_SUSPEND_PREPARE, disable the motor and in case of PM_POST_SUSPEND,
enable motor device. And do refactor the code for the readability.

Change-Id: I2e51fab75d5fcf5dc16b0eabd5212d4fb5a75540
Signed-off-by: jeongsup.jeong <jeongsup.jeong@samsung.com>
[cw00.choi: Add commig-msg as the public style]
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
4 years agousb: gadget: f_fs: Limit data buffer size to a single page 96/232896/1 accepted/tizen/unified/20200510.220449 submit/tizen/20200508.072818
Dongwoo Lee [Fri, 8 May 2020 06:30:40 +0000 (15:30 +0900)]
usb: gadget: f_fs: Limit data buffer size to a single page

Large size request from sdbd usually causes memory allocation failure
in case of memory shortage. The failure is not handled by sdbd
properly and thus it makes sdbd a hung state. To prevent this
situation, this patch limits data buffer size to a single page so as
to guarantee memory allocation success.

Change-Id: I4eada6c8beca337cf93182b6d860209cc80d044d
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
4 years agoRevert "usb: gadget: f_fs: Give chance to retry malloc for large size buffer" 95/232895/1
Dongwoo Lee [Fri, 8 May 2020 06:50:04 +0000 (15:50 +0900)]
Revert "usb: gadget: f_fs: Give chance to retry malloc for large size buffer"

This reverts commit 868788459b5403009d82575fd4834efbfe11e7b2.

That commit turns out that causing write (in transfer) failure when
buffer allocation is failed due to memory shortage. So, it reveals
multiple tries is not complete solution.

Change-Id: Ie924272060dd689e378c59fdca1ea2ddfa571fb2
Reported-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
4 years agoBluetooth: Add GATT data batching 64/229264/5 accepted/tizen/unified/20200402.155630 submit/tizen/20200331.090714
Wootak Jung [Wed, 1 Apr 2020 02:52:54 +0000 (11:52 +0900)]
Bluetooth: Add GATT data batching

GATT batching is a function to reduce the AP's wake every time it receives the
GATT data. If user set the timeout or threshold of the number of data packets
and correspond to one condition, the collected data will be raised in order.

Change-Id: I6968b73bd562a3b7a382f3253bb04dfcef399b57
Signed-off-by: Deokhyun Kim <dukan.kim@samsung.com>
Signed-off-by: Wootak Jung <wootak.jung@samsung.com>
4 years agoInput: tizen_bezel: Change event value of the bezel device 95/220495/7 accepted/tizen/unified/20200324.101622 submit/tizen/20200323.012640
lsmin.lee [Fri, 3 Jan 2020 09:31:42 +0000 (18:31 +0900)]
Input: tizen_bezel: Change event value of the bezel device

Until Tizen 5.0, for bezel input device, its event value was in
between -2 and 2, but value 1. meant starting movement to
counter clockwiseare or clockwise, and value -1, meant moving back
to original position, never used. Change event value of the bezel
device for Tizen 5.5 and later version.

It changes bezel input driver event interface, so user input
framework for bezel input should be also changed.

Ref: https://review.tizen.org/gerrit/#/c/platform/upstream/enlightenment/+/220346/

Signed-off-by: lsmin.lee <lsmin.lee@samsung.com>
[sw0312.kim: adjust commit-msg to public style]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I1293db138c71d2a5c4f52b827f3a441b47710449

4 years agoBluetooth: SMP: fix crash in unpairing 49/226349/4 accepted/tizen/unified/20200302.125741 submit/tizen/20200302.034238
Matias Karhumaa [Wed, 26 Sep 2018 06:13:46 +0000 (09:13 +0300)]
Bluetooth: SMP: fix crash in unpairing

[ Upstream commit cb28c306b93b71f2741ce1a5a66289db26715f4d ]

In case unpair_device() was called through mgmt interface at the same time
when pairing was in progress, Bluetooth kernel module crash was seen.

[  600.351225] general protection fault: 0000 [#1] SMP PTI
[  600.351235] CPU: 1 PID: 11096 Comm: btmgmt Tainted: G           OE     4.19.0-rc1+ #1
[  600.351238] Hardware name: Dell Inc. Latitude E5440/08RCYC, BIOS A18 05/14/2017
[  600.351272] RIP: 0010:smp_chan_destroy.isra.10+0xce/0x2c0 [bluetooth]
[  600.351276] Code: c0 0f 84 b4 01 00 00 80 78 28 04 0f 84 53 01 00 00 4d 85 ed 0f 85 ab 00 00 00 48 8b 08 48 8b 50 08 be 10 00 00 00 48 89 51 08 <48> 89 0a 48 b9 00 02 00 00 00 00 ad de 48 89 48 08 48 8b 83 00 01
[  600.351279] RSP: 0018:ffffa9be839b3b50 EFLAGS: 00010246
[  600.351282] RAX: ffff9c999ac565a0 RBX: ffff9c9996e98c00 RCX: ffff9c999aa28b60
[  600.351285] RDX: dead000000000200 RSI: 0000000000000010 RDI: ffff9c999e403500
[  600.351287] RBP: ffffa9be839b3b70 R08: 0000000000000000 R09: ffffffff92a25c00
[  600.351290] R10: ffffa9be839b3ae8 R11: 0000000000000001 R12: ffff9c995375b800
[  600.351292] R13: 0000000000000000 R14: ffff9c99619a5000 R15: ffff9c9962a01c00
[  600.351295] FS:  00007fb2be27c700(0000) GS:ffff9c999e880000(0000) knlGS:0000000000000000
[  600.351298] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  600.351300] CR2: 00007fb2bdadbad0 CR3: 000000041c328001 CR4: 00000000001606e0
[  600.351302] Call Trace:
[  600.351325]  smp_failure+0x4f/0x70 [bluetooth]
[  600.351345]  smp_cancel_pairing+0x74/0x80 [bluetooth]
[  600.351370]  unpair_device+0x1c1/0x330 [bluetooth]
[  600.351399]  hci_sock_sendmsg+0x960/0x9f0 [bluetooth]
[  600.351409]  ? apparmor_socket_sendmsg+0x1e/0x20
[  600.351417]  sock_sendmsg+0x3e/0x50
[  600.351422]  sock_write_iter+0x85/0xf0
[  600.351429]  do_iter_readv_writev+0x12b/0x1b0
[  600.351434]  do_iter_write+0x87/0x1a0
[  600.351439]  vfs_writev+0x98/0x110
[  600.351443]  ? ep_poll+0x16d/0x3d0
[  600.351447]  ? ep_modify+0x73/0x170
[  600.351451]  do_writev+0x61/0xf0
[  600.351455]  ? do_writev+0x61/0xf0
[  600.351460]  __x64_sys_writev+0x1c/0x20
[  600.351465]  do_syscall_64+0x5a/0x110
[  600.351471]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[  600.351474] RIP: 0033:0x7fb2bdb62fe0
[  600.351477] Code: 73 01 c3 48 8b 0d b8 6e 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 69 c7 2c 00 00 75 10 b8 14 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 de 80 01 00 48 89 04 24
[  600.351479] RSP: 002b:00007ffe062cb8f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000014
[  600.351484] RAX: ffffffffffffffda RBX: 000000000255b3d0 RCX: 00007fb2bdb62fe0
[  600.351487] RDX: 0000000000000001 RSI: 00007ffe062cb920 RDI: 0000000000000004
[  600.351490] RBP: 00007ffe062cb920 R08: 000000000255bd80 R09: 0000000000000000
[  600.351494] R10: 0000000000000353 R11: 0000000000000246 R12: 0000000000000001
[  600.351497] R13: 00007ffe062cbbe0 R14: 0000000000000000 R15: 0000000000000000
[  600.351501] Modules linked in: algif_hash algif_skcipher af_alg cmac ipt_MASQUERADE nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo iptable_nat nf_nat_ipv4 xt_addrtype iptable_filter ip_tables xt_conntrack x_tables nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c br_netfilter bridge stp llc overlay arc4 nls_iso8859_1 dm_crypt intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp dell_laptop kvm_intel crct10dif_pclmul dell_smm_hwmon crc32_pclmul ghash_clmulni_intel pcbc aesni_intel aes_x86_64 crypto_simd cryptd glue_helper intel_cstate intel_rapl_perf uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev media hid_multitouch input_leds joydev serio_raw dell_wmi snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic dell_smbios dcdbas sparse_keymap
[  600.351569]  snd_hda_intel btusb snd_hda_codec btrtl btbcm btintel snd_hda_core bluetooth(OE) snd_hwdep snd_pcm iwlmvm ecdh_generic wmi_bmof dell_wmi_descriptor snd_seq_midi mac80211 snd_seq_midi_event lpc_ich iwlwifi snd_rawmidi snd_seq snd_seq_device snd_timer cfg80211 snd soundcore mei_me mei dell_rbtn dell_smo8800 mac_hid parport_pc ppdev lp parport autofs4 hid_generic usbhid hid i915 nouveau kvmgt vfio_mdev mdev vfio_iommu_type1 vfio kvm irqbypass i2c_algo_bit ttm drm_kms_helper syscopyarea sysfillrect sysimgblt mxm_wmi psmouse ahci sdhci_pci cqhci libahci fb_sys_fops sdhci drm e1000e video wmi
[  600.351637] ---[ end trace e49e9f1df09c94fb ]---
[  600.351664] RIP: 0010:smp_chan_destroy.isra.10+0xce/0x2c0 [bluetooth]
[  600.351666] Code: c0 0f 84 b4 01 00 00 80 78 28 04 0f 84 53 01 00 00 4d 85 ed 0f 85 ab 00 00 00 48 8b 08 48 8b 50 08 be 10 00 00 00 48 89 51 08 <48> 89 0a 48 b9 00 02 00 00 00 00 ad de 48 89 48 08 48 8b 83 00 01
[  600.351669] RSP: 0018:ffffa9be839b3b50 EFLAGS: 00010246
[  600.351672] RAX: ffff9c999ac565a0 RBX: ffff9c9996e98c00 RCX: ffff9c999aa28b60
[  600.351674] RDX: dead000000000200 RSI: 0000000000000010 RDI: ffff9c999e403500
[  600.351676] RBP: ffffa9be839b3b70 R08: 0000000000000000 R09: ffffffff92a25c00
[  600.351679] R10: ffffa9be839b3ae8 R11: 0000000000000001 R12: ffff9c995375b800
[  600.351681] R13: 0000000000000000 R14: ffff9c99619a5000 R15: ffff9c9962a01c00
[  600.351684] FS:  00007fb2be27c700(0000) GS:ffff9c999e880000(0000) knlGS:0000000000000000
[  600.351686] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  600.351689] CR2: 00007fb2bdadbad0 CR3: 000000041c328001 CR4: 00000000001606e0

Crash happened because list_del_rcu() was called twice for smp->ltk. This
was possible if unpair_device was called right after ltk was generated
but before keys were distributed.

In this commit smp_cancel_pairing was refactored to cancel pairing if it
is in progress and otherwise just removes keys. Once keys are removed from
rcu list, pointers to smp context's keys are set to NULL to make sure
removed list items are not accessed later.

This commit also adjusts the functionality of mgmt unpair_device() little
bit. Previously pairing was canceled only if pairing was in state that
keys were already generated. With this commit unpair_device() cancels
pairing already in earlier states.

Bug was found by fuzzing kernel SMP implementation using Synopsys
Defensics.

Reported-by: Pekka Oikarainen <pekka.oikarainen@synopsys.com>
Signed-off-by: Matias Karhumaa <matias.karhumaa@gmail.com>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[dh79.pyun: apply mainline stable linux-4.9.y commit 83e158f93d66 to handle BT crash issue]
Signed-off-by: DoHyun Pyun <dh79.pyun@samsung.com>
Change-Id: Iaa7196d5bb49fe993ba9ca0bf9b9a1eece7b6200

4 years agoBluetooth: Fix missing encryption refresh on Security Request 48/226348/3
Szymon Janc [Mon, 26 Feb 2018 14:41:53 +0000 (15:41 +0100)]
Bluetooth: Fix missing encryption refresh on Security Request

commit 64e759f58f128730b97a3c3a26d283c075ad7c86 upstream.

If Security Request is received on connection that is already encrypted
with sufficient security master should perform encryption key refresh
procedure instead of just ignoring Slave Security Request
(Core Spec 5.0 Vol 3 Part H 2.4.6).

> ACL Data RX: Handle 3585 flags 0x02 dlen 6
      SMP: Security Request (0x0b) len 1
        Authentication requirement: Bonding, No MITM, SC, No Keypresses (0x09)
< HCI Command: LE Start Encryption (0x08|0x0019) plen 28
        Handle: 3585
        Random number: 0x0000000000000000
        Encrypted diversifier: 0x0000
        Long term key: 44264272a5c426a9e868f034cf0e69f3
> HCI Event: Command Status (0x0f) plen 4
      LE Start Encryption (0x08|0x0019) ncmd 1
        Status: Success (0x00)
> HCI Event: Encryption Key Refresh Complete (0x30) plen 3
        Status: Success (0x00)
        Handle: 3585

Signed-off-by: Szymon Janc <szymon.janc@codecoup.pl>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[dh79.pyun: apply mainline stable linux-4.9.y commit 24382a60331d to handle BT issue]
Signed-off-by: DoHyun Pyun <dh79.pyun@samsung.com>
Change-Id: Ifb94f389253d8515bcc4676fffcfd73c09f1242c

4 years agoarm64: relocatable: fix inconsistencies in linker script and options 80/221380/1 accepted/tizen/unified/20200102.220848 submit/tizen/20200102.014302
Ard Biesheuvel [Mon, 3 Dec 2018 19:58:05 +0000 (20:58 +0100)]
arm64: relocatable: fix inconsistencies in linker script and options

commit 3bbd3db86470c701091fb1d67f1fab6621debf50 upstream.

readelf complains about the section layout of vmlinux when building
with CONFIG_RELOCATABLE=y (for KASLR):

  readelf: Warning: [21]: Link field (0) should index a symtab section.
  readelf: Warning: [21]: Info field (0) should index a relocatable section.

Also, it seems that our use of '-pie -shared' is contradictory, and
thus ambiguous. In general, the way KASLR is wired up at the moment
is highly tailored to how ld.bfd happens to implement (and conflate)
PIE executables and shared libraries, so given the current effort to
support other toolchains, let's fix some of these issues as well.

- Drop the -pie linker argument and just leave -shared. In ld.bfd,
  the differences between them are unclear (except for the ELF type
  of the produced image [0]) but lld chokes on seeing both at the
  same time.

- Rename the .rela output section to .rela.dyn, as is customary for
  shared libraries and PIE executables, so that it is not misidentified
  by readelf as a static relocation section (producing the warnings
  above).

- Pass the -z notext and -z norelro options to explicitly instruct the
  linker to permit text relocations, and to omit the RELRO program
  header (which requires a certain section layout that we don't adhere
  to in the kernel). These are the defaults for current versions of
  ld.bfd.

- Discard .eh_frame and .gnu.hash sections to avoid them from being
  emitted between .head.text and .text, screwing up the section layout.

These changes only affect the ELF image, and produce the same binary
image.

[0] b9dce7f1ba01 ("arm64: kernel: force ET_DYN ELF type for ...")

Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Peter Smith <peter.smith@linaro.org>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Found solution for Tizen 6.0 toolchain by Mikhail Kashkarov <m.kashkarov@partner.samsung.com> ]
[sw0312.kim: backport stable linux-4.14.y commit f21ce3cdff2f for gcc 9 built image]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I0ddfedad20188dcd9d7b416370e95d175b595db0

4 years agoarm64: remove no-op -p linker flag 79/221379/1
Greg Hackmann [Tue, 27 Nov 2018 19:15:20 +0000 (11:15 -0800)]
arm64: remove no-op -p linker flag

(commit 1a381d4a0a9a0f999a13faaba22bf6b3fc80dcb9 upstream)

Linking the ARM64 defconfig kernel with LLVM lld fails with the error:

  ld.lld: error: unknown argument: -p
  Makefile:1015: recipe for target 'vmlinux' failed

Without this flag, the ARM64 defconfig kernel successfully links with
lld and boots on Dragonboard 410c.

After digging through binutils source and changelogs, it turns out that
-p is only relevant to ancient binutils installations targeting 32-bit
ARM.  binutils accepts -p for AArch64 too, but it's always been
undocumented and silently ignored.  A comment in
ld/emultempl/aarch64elf.em explains that it's "Only here for backwards
compatibility".

Since this flag is a no-op on ARM64, we can safely drop it.

Acked-by: Will Deacon <will.deacon@arm.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Greg Hackmann <ghackmann@google.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[sw0312.kim: cherry-pick stable linux-4.9.y commit 272991176af2 for gcc 9 build]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I47c82851c886f2b1d3af3e65ef7e7131ea877b62

4 years agoarm64: prevent regressions in compressed kernel image size when upgrading to binutils... 78/221378/1
Nick Desaulniers [Fri, 27 Oct 2017 16:33:41 +0000 (09:33 -0700)]
arm64: prevent regressions in compressed kernel image size when upgrading to binutils 2.27

[ Upstream commit fd9dde6abcb9bfe6c6bee48834e157999f113971 ]

Upon upgrading to binutils 2.27, we found that our lz4 and gzip
compressed kernel images were significantly larger, resulting is 10ms
boot time regressions.

As noted by Rahul:
"aarch64 binaries uses RELA relocations, where each relocation entry
includes an addend value. This is similar to x86_64.  On x86_64, the
addend values are also stored at the relocation offset for relative
relocations. This is an optimization: in the case where code does not
need to be relocated, the loader can simply skip processing relative
relocations.  In binutils-2.25, both bfd and gold linkers did this for
x86_64, but only the gold linker did this for aarch64.  The kernel build
here is using the bfd linker, which stored zeroes at the relocation
offsets for relative relocations.  Since a set of zeroes compresses
better than a set of non-zero addend values, this behavior was resulting
in much better lz4 compression.

The bfd linker in binutils-2.27 is now storing the actual addend values
at the relocation offsets. The behavior is now consistent with what it
does for x86_64 and what gold linker does for both architectures.  The
change happened in this upstream commit:
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=1f56df9d0d5ad89806c24e71f296576d82344613
Since a bunch of zeroes got replaced by non-zero addend values, we see
the side effect of lz4 compressed image being a bit bigger.

To get the old behavior from the bfd linker, "--no-apply-dynamic-relocs"
flag can be used:
$ LDFLAGS="--no-apply-dynamic-relocs" make
With this flag, the compressed image size is back to what it was with
binutils-2.25.

If the kernel is using ASLR, there aren't additional runtime costs to
--no-apply-dynamic-relocs, as the relocations will need to be applied
again anyway after the kernel is relocated to a random address.

If the kernel is not using ASLR, then presumably the current default
behavior of the linker is better. Since the static linker performed the
dynamic relocs, and the kernel is not moved to a different address at
load time, it can skip applying the relocations all over again."

Some measurements:

$ ld -v
GNU ld (binutils-2.25-f3d35cf6) 2.25.51.20141117
                    ^
$ ls -l vmlinux
-rwxr-x--- 1 ndesaulniers eng 300652760 Oct 26 11:57 vmlinux
$ ls -l Image.lz4-dtb
-rw-r----- 1 ndesaulniers eng 16932627 Oct 26 11:57 Image.lz4-dtb

$ ld -v
GNU ld (binutils-2.27-53dd00a1) 2.27.0.20170315
                    ^
pre patch:
$ ls -l vmlinux
-rwxr-x--- 1 ndesaulniers eng 300376208 Oct 26 11:43 vmlinux
$ ls -l Image.lz4-dtb
-rw-r----- 1 ndesaulniers eng 18159474 Oct 26 11:43 Image.lz4-dtb

post patch:
$ ls -l vmlinux
-rwxr-x--- 1 ndesaulniers eng 300376208 Oct 26 12:06 vmlinux
$ ls -l Image.lz4-dtb
-rw-r----- 1 ndesaulniers eng 16932466 Oct 26 12:06 Image.lz4-dtb

By Siqi's measurement w/ gzip:
binutils 2.27 with this patch (with --no-apply-dynamic-relocs):
Image 41535488
Image.gz 13404067

binutils 2.27 without this patch (without --no-apply-dynamic-relocs):
Image 41535488
Image.gz 14125516

Any compression scheme should be able to get better results from the
longer runs of zeros, not just GZIP and LZ4.

10ms boot time savings isn't anything to get excited about, but users of
arm64+compression+bfd-2.27 should not have to pay a penalty for no
runtime improvement.

Reported-by: Gopinath Elanchezhian <gelanchezhian@google.com>
Reported-by: Sindhuri Pentyala <spentyala@google.com>
Reported-by: Wei Wang <wvw@google.com>
Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Suggested-by: Rahul Chaudhry <rahulchaudhry@google.com>
Suggested-by: Siqi Lin <siqilin@google.com>
Suggested-by: Stephen Hines <srhines@google.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
[will: added comment to Makefile]
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[sw0312.kim: cherry-pick stable linux-4.9.y commit b7ada2c0ea29 for gcc 9 build]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I1b1afff5c639be9ab429f23b38b144c9cc8a7240

4 years agoarm64: Don't unconditionally add -Wno-psabi to KBUILD_CFLAGS 98/221298/1 accepted/tizen/unified/20200101.120530 submit/tizen/20191231.055421
Nathan Chancellor [Tue, 11 Jun 2019 17:19:32 +0000 (10:19 -0700)]
arm64: Don't unconditionally add -Wno-psabi to KBUILD_CFLAGS

This is a GCC only option, which warns about ABI changes within GCC, so
unconditionally adding it breaks Clang with tons of:

warning: unknown warning option '-Wno-psabi' [-Wunknown-warning-option]

and link time failures:

ld.lld: error: undefined symbol: __efistub___stack_chk_guard
>>> referenced by arm-stub.c:73
(/home/nathan/cbl/linux/drivers/firmware/efi/libstub/arm-stub.c:73)
>>>               arm-stub.stub.o:(__efistub_install_memreserve_table)
in archive ./drivers/firmware/efi/libstub/lib.a

These failures come from the lack of -fno-stack-protector, which is
added via cc-option in drivers/firmware/efi/libstub/Makefile. When an
unknown flag is added to KBUILD_CFLAGS, clang will noisily warn that it
is ignoring the option like above, unlike gcc, who will just error.

$ echo "int main() { return 0; }" > tmp.c

$ clang -Wno-psabi tmp.c; echo $?
warning: unknown warning option '-Wno-psabi' [-Wunknown-warning-option]
1 warning generated.
0

$ gcc -Wsometimes-uninitialized tmp.c; echo $?
gcc: error: unrecognized command line option
‘-Wsometimes-uninitialized’; did you mean ‘-Wmaybe-uninitialized’?
1

For cc-option to work properly with clang and behave like gcc, -Werror
is needed, which was done in commit c3f0d0bc5b01 ("kbuild, LLVMLinux:
Add -Werror to cc-option to support clang").

$ clang -Werror -Wno-psabi tmp.c; echo $?
error: unknown warning option '-Wno-psabi'
[-Werror,-Wunknown-warning-option]
1

As a consequence of this, when an unknown flag is unconditionally added
to KBUILD_CFLAGS, it will cause cc-option to always fail and those flags
will never get added:

$ clang -Werror -Wno-psabi -fno-stack-protector tmp.c; echo $?
error: unknown warning option '-Wno-psabi'
[-Werror,-Wunknown-warning-option]
1

This can be seen when compiling the whole kernel as some warnings that
are normally disabled (see below) show up. The full list of flags
missing from drivers/firmware/efi/libstub are the following (gathered
from diffing .arm64-stub.o.cmd):

-fno-delete-null-pointer-checks
-Wno-address-of-packed-member
-Wframe-larger-than=2048
-Wno-unused-const-variable
-fno-strict-overflow
-fno-merge-all-constants
-fno-stack-check
-Werror=date-time
-Werror=incompatible-pointer-types
-ffreestanding
-fno-stack-protector

Use cc-disable-warning so that it gets disabled for GCC and does nothing
for Clang.

Fixes: ebcc5928c5d9 ("arm64: Silence gcc warnings about arch ABI drift")
Link: https://github.com/ClangBuiltLinux/linux/issues/511
Reported-by: Qian Cai <cai@lca.pw>
Acked-by: Dave Martin <Dave.Martin@arm.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
[sw0312.kim: backport mainline commit fa63da2ab046 for gcc 9 build]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I4b6f775dd115a8eb92080c570b7727c143ede17c

4 years agoarm64: Silence gcc warnings about arch ABI drift 97/221297/1
Dave Martin [Thu, 6 Jun 2019 10:33:43 +0000 (11:33 +0100)]
arm64: Silence gcc warnings about arch ABI drift

Since GCC 9, the compiler warns about evolution of the
platform-specific ABI, in particular relating for the marshaling of
certain structures involving bitfields.

The kernel is a standalone binary, and of course nobody would be
so stupid as to expose structs containing bitfields as function
arguments in ABI.  (Passing a pointer to such a struct, however
inadvisable, should be unaffected by this change.  perf and various
drivers rely on that.)

So these warnings do more harm than good: turn them off.

We may miss warnings about future ABI drift, but that's too bad.
Future ABI breaks of this class will have to be debugged and fixed
the traditional way unless the compiler evolves finer-grained
diagnostics.

Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
[sw0312.kim: backport mainline commit ebcc5928c5d9 for gcc 9 build]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: Ic7620fb77291c55e8237495d99285c8a14eac326

4 years agoInput: zxt_ztm620_ts: Remove possible overflow by using strlcat() 20/220820/2
Seung-Woo Kim [Mon, 23 Dec 2019 10:48:32 +0000 (19:48 +0900)]
Input: zxt_ztm620_ts: Remove possible overflow by using strlcat()

The strncat() from a buffer to other buffer with same size can
make overflow. Remove the possible overflow by replacing strncat()
to strlcat().

Change-Id: I2d98f7548c87e048726bf4c3dc7ed942270565d9
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
4 years agoInput: zxt_ztm620_ts: Repalce meaningless strncat() to strcat() 19/220819/2
Seung-Woo Kim [Mon, 23 Dec 2019 10:01:44 +0000 (19:01 +0900)]
Input: zxt_ztm620_ts: Repalce meaningless strncat() to strcat()

The strncat() with length from strlen() of copied string is
completely meaningless. Just replace the usage of strncat() to
strcat().

Change-Id: Ibdd75a6cc7d5e2f9e80f20535f7d61b278fc29a3
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
4 years agosoc: samsung: cal-if: fix not to calculate array size from null 18/220818/2
Seung-Woo Kim [Mon, 23 Dec 2019 08:23:37 +0000 (17:23 +0900)]
soc: samsung: cal-if: fix not to calculate array size from null

Calculating array size from null causes sizeof-pointer-div warning.
Fix not to calculate array size from null by adding pll macro
without NULL array.

Change-Id: I7002376523bd42cedaebc6443135c8410e5a1c46
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
4 years agovideo: fbdev: exynos: dpu9110: panel: s6e36w3x01: remove buffer overflow 17/220817/2
Seung-Woo Kim [Mon, 23 Dec 2019 08:29:02 +0000 (17:29 +0900)]
video: fbdev: exynos: dpu9110: panel: s6e36w3x01: remove buffer overflow

The memcpy to buffer has out of bounds for array. Remove the
buffer overflow for by adding additional array length.

Change-Id: I0aa5974fd39a6a7f705740ce1dcbf6ce15c2e935
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
4 years agoAsoC: speedy: fix sizeof-pointer-memaccess for strncpy() 16/220816/2
Seung-Woo Kim [Mon, 23 Dec 2019 07:20:00 +0000 (16:20 +0900)]
AsoC: speedy: fix sizeof-pointer-memaccess for strncpy()

The strncpy() is done with sizeof() for source. Fix warning from
sizeof-pointer-memaccess by replacing sizeof() for destination.

Change-Id: I2e4bbdda84e90391d8767358ebebb12bdc10154e
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
4 years agonet: bcmdhd: Fix string concatenate with strncat() 15/220815/2
Seung-Woo Kim [Mon, 23 Dec 2019 07:58:25 +0000 (16:58 +0900)]
net: bcmdhd: Fix string concatenate with strncat()

There is stringop-overflow warning to use strncat and bound check
for buffer size for the string is already done. Fix string
concatenate with strncat() by replacing with strcat().

Change-Id: I8c009e4d76f5044601bacd596d4ca872bb69fd1f
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
4 years agoarm64: tizen_tw3_defconfig: Enable CONFIG_CRYPTO_CCM 41/221041/2
Anupam Roy [Thu, 26 Dec 2019 11:26:02 +0000 (16:56 +0530)]
arm64: tizen_tw3_defconfig: Enable CONFIG_CRYPTO_CCM

Enable CONFIG_CRYPTO_CCM config option for using
AEAD-AES_CCM encryption. AEAD socket with
AES_CCM cipher type is used by Bluetooth Mesh
functionality for encryption & decryption.

Change-Id: I8b940288c2763ebc3007d5a419329f392b41ad8b
Signed-off-by: Anupam Roy <anupam.r@samsung.com>
4 years agoarm64: tizen_tw3_defconfig: sync USB_CONFIGFS related config options 56/221056/1
Seung-Woo Kim [Fri, 27 Dec 2019 00:59:16 +0000 (09:59 +0900)]
arm64: tizen_tw3_defconfig: sync USB_CONFIGFS related config options

After CONFIG_USB_CONFIGFS is enabled, defconfig was not fully
updated. Sync realted config options.

Change-Id: I96c99483933f0c84bd48b0f67110a469bf245ef7
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
4 years agocfg80211: Fix array-bounds warning in fragment copy 14/220814/1
Matthias Kaehlcke [Thu, 13 Apr 2017 17:05:04 +0000 (10:05 -0700)]
cfg80211: Fix array-bounds warning in fragment copy

commit aa1702dd162f420bf85ecef0c77686ef0dbc1496 upstream.

__ieee80211_amsdu_copy_frag intentionally initializes a pointer to
array[-1] to increment it later to valid values. clang rightfully
generates an array-bounds warning on the initialization statement.

Initialize the pointer to array[0] and change the algorithm from
increment before to increment after consume.

Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Cc: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[sw0312.kim: cherry-pick stable linux-4.9.y commit 4bb797afd7ba for gcc 9 build]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: Ibb581c74dc67fcc867f7fa58d20cb1b225caa852

4 years agoip_tunnel: Fix name string concatenate in __ip_tunnel_create() 13/220813/1
Sultan Alsawaf [Wed, 6 Jun 2018 22:56:54 +0000 (15:56 -0700)]
ip_tunnel: Fix name string concatenate in __ip_tunnel_create()

commit 000ade8016400d93b4d7c89970d96b8c14773d45 upstream.

By passing a limit of 2 bytes to strncat, strncat is limited to writing
fewer bytes than what it's supposed to append to the name here.

Since the bounds are checked on the line above this, just remove the string
bounds checks entirely since they're unneeded.

Signed-off-by: Sultan Alsawaf <sultanxda@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[sw0312.kim: cherry-pick stable linux-4.9.y commit 5569c10858be for gcc 9 build]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: Ida4f04d469c4d91f12faa5fe46bd443c43bfe333

4 years agotracing: Silence GCC 9 array bounds warning 12/220812/1
Miguel Ojeda [Thu, 23 May 2019 12:45:35 +0000 (14:45 +0200)]
tracing: Silence GCC 9 array bounds warning

commit 0c97bf863efce63d6ab7971dad811601e6171d2f upstream.

Starting with GCC 9, -Warray-bounds detects cases when memset is called
starting on a member of a struct but the size to be cleared ends up
writing over further members.

Such a call happens in the trace code to clear, at once, all members
after and including `seq` on struct trace_iterator:

    In function 'memset',
        inlined from 'ftrace_dump' at kernel/trace/trace.c:8914:3:
    ./include/linux/string.h:344:9: warning: '__builtin_memset' offset
    [8505, 8560] from the object at 'iter' is out of the bounds of
    referenced subobject 'seq' with type 'struct trace_seq' at offset
    4368 [-Warray-bounds]
      344 |  return __builtin_memset(p, c, size);
          |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~

In order to avoid GCC complaining about it, we compute the address
ourselves by adding the offsetof distance instead of referring
directly to the member.

Since there are two places doing this clear (trace.c and trace_kdb.c),
take the chance to move the workaround into a single place in
the internal header.

Link: http://lkml.kernel.org/r/20190523124535.GA12931@gmail.com
Signed-off-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
[ Removed unnecessary parenthesis around "iter" ]
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[sw0312.kim: cherry-pick stable linux-4.9.y commit 2e41539ee26f for gcc 9 build]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I82d986a1e1a6a447c2fd3b5c3af3145192e72748

4 years agogcc-9: silence 'address-of-packed-member' warning 11/220811/1
Linus Torvalds [Wed, 1 May 2019 18:05:41 +0000 (11:05 -0700)]
gcc-9: silence 'address-of-packed-member' warning

commit 6f303d60534c46aa1a239f29c321f95c83dda748 upstream.

We already did this for clang, but now gcc has that warning too.  Yes,
yes, the address may be unaligned.  And that's kind of the point.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[sw0312.kim: cherry-pick stable linux-4.9.y commit 7601d81506ef for gcc 9 build]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: Id774c5d5a37b7761a7792be0fedc7282f19d45f8

4 years agounifdef: use memcpy instead of strncpy 10/220810/1
Linus Torvalds [Fri, 30 Nov 2018 22:45:01 +0000 (14:45 -0800)]
unifdef: use memcpy instead of strncpy

commit 38c7b224ce22c25fed04007839edf974bd13439d upstream.

New versions of gcc reasonably warn about the odd pattern of

strncpy(p, q, strlen(q));

which really doesn't make sense: the strncpy() ends up being just a slow
and odd way to write memcpy() in this case.

There was a comment about _why_ the code used strncpy - to avoid the
terminating NUL byte, but memcpy does the same and avoids the warning.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[sw0312.kim: cherry-pick stable linux-4.9.y commit 0d4a2de44713 for gcc 9 build]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I3adb0d708af7d8a55216d6c81d1e691b8d30e8c1

4 years agoarm64, vdso: Define vdso_{start,end} as array 09/220809/1
Kees Cook [Fri, 5 Jul 2019 18:47:20 +0000 (20:47 +0200)]
arm64, vdso: Define vdso_{start,end} as array

Commit dbbb08f500d6146398b794fdc68a8e811366b451 upstream.

Adjust vdso_{start|end} to be char arrays to avoid compile-time analysis
that flags "too large" memcmp() calls with CONFIG_FORTIFY_SOURCE.

Cc: Jisheng Zhang <jszhang@marvell.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Suggested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[sw0312.kim: cherry-pick stable linux-4.9.y commit 830d3a71e1ce for gcc 9 build]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I32aa68e1365d0389f05ab456f82b3b72f10b60da

4 years agoKbuild: suppress packed-not-aligned warning for default setting only 08/220808/1
Xiongfeng Wang [Thu, 11 Jan 2018 09:22:29 +0000 (17:22 +0800)]
Kbuild: suppress packed-not-aligned warning for default setting only

commit 321cb0308a9e76841394b4bbab6a1107cfedbae0 upstream.

gcc-8 reports many -Wpacked-not-aligned warnings. The below are some
examples.

./include/linux/ceph/msgr.h:67:1: warning: alignment 1 of 'struct
ceph_entity_addr' is less than 8 [-Wpacked-not-aligned]
 } __attribute__ ((packed));

./include/linux/ceph/msgr.h:67:1: warning: alignment 1 of 'struct
ceph_entity_addr' is less than 8 [-Wpacked-not-aligned]
 } __attribute__ ((packed));

./include/linux/ceph/msgr.h:67:1: warning: alignment 1 of 'struct
ceph_entity_addr' is less than 8 [-Wpacked-not-aligned]
 } __attribute__ ((packed));

This patch suppresses this kind of warnings for default setting.

Signed-off-by: Xiongfeng Wang <xiongfeng.wang@linaro.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[sw0312.kim: cherry-pick stable linux-4.9.y commit dfb64b8c3d26 for gcc 9 build]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I9fe83e410fbf2ddd0ce52842ed1f5c24efce260a

4 years agodisable stringop truncation warnings for now 07/220807/1
Stephen Rothwell [Thu, 30 Aug 2018 21:47:28 +0000 (07:47 +1000)]
disable stringop truncation warnings for now

commit 217c3e0196758662aa0429863b09d1c13da1c5d6 upstream.

They are too noisy

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[sw0312.kim: cherry-pick stable linux-4.9.y commit 5e2669c978b2 for gcc 9 build]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I57286951ce59491105cc89ec99277a180b3c7478

4 years agokconfig: Avoid format overflow warning from GCC 8.1 06/220806/1
Nathan Chancellor [Sat, 2 Jun 2018 16:02:09 +0000 (09:02 -0700)]
kconfig: Avoid format overflow warning from GCC 8.1

commit 2ae89c7a82ea9d81a19b4fc2df23bef4b112f24e upstream.

In file included from scripts/kconfig/zconf.tab.c:2485:
scripts/kconfig/confdata.c: In function ‘conf_write’:
scripts/kconfig/confdata.c:773:22: warning: ‘%s’ directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
  sprintf(newname, "%s%s", dirname, basename);
                      ^~
scripts/kconfig/confdata.c:773:19: note: assuming directive output of 7 bytes
  sprintf(newname, "%s%s", dirname, basename);
                   ^~~~~~
scripts/kconfig/confdata.c:773:2: note: ‘sprintf’ output 1 or more bytes (assuming 4104) into a destination of size 4097
  sprintf(newname, "%s%s", dirname, basename);
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
scripts/kconfig/confdata.c:776:23: warning: ‘.tmpconfig.’ directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
   sprintf(tmpname, "%s.tmpconfig.%d", dirname, (int)getpid());
                       ^~~~~~~~~~~
scripts/kconfig/confdata.c:776:3: note: ‘sprintf’ output between 13 and 4119 bytes into a destination of size 4097
   sprintf(tmpname, "%s.tmpconfig.%d", dirname, (int)getpid());
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Increase the size of tmpname and newname to make GCC happy.

Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[sw0312.kim: cherry-pick stable linux-4.9.y commit 1ec1dfba0835 for gcc 9 build]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I7ebafa60f7703732795fe226b1c1eb8c39a27c28

4 years agoexec: avoid gcc-8 warning for get_task_comm 05/220805/1
Arnd Bergmann [Thu, 14 Dec 2017 23:32:41 +0000 (15:32 -0800)]
exec: avoid gcc-8 warning for get_task_comm

commit 3756f6401c302617c5e091081ca4d26ab604bec5 upstream.

gcc-8 warns about using strncpy() with the source size as the limit:

  fs/exec.c:1223:32: error: argument to 'sizeof' in 'strncpy' call is the same expression as the source; did you mean to use the size of the destination? [-Werror=sizeof-pointer-memaccess]

This is indeed slightly suspicious, as it protects us from source
arguments without NUL-termination, but does not guarantee that the
destination is terminated.

This keeps the strncpy() to ensure we have properly padded target
buffer, but ensures that we use the correct length, by passing the
actual length of the destination buffer as well as adding a build-time
check to ensure it is exactly TASK_COMM_LEN.

There are only 23 callsites which I all reviewed to ensure this is
currently the case.  We could get away with doing only the check or
passing the right length, but it doesn't hurt to do both.

Link: http://lkml.kernel.org/r/20171205151724.1764896-1-arnd@arndb.de
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Suggested-by: Kees Cook <keescook@chromium.org>
Acked-by: Kees Cook <keescook@chromium.org>
Acked-by: Ingo Molnar <mingo@kernel.org>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Serge Hallyn <serge@hallyn.com>
Cc: James Morris <james.l.morris@oracle.com>
Cc: Aleksa Sarai <asarai@suse.de>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Frederic Weisbecker <frederic@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[sw0312.kim: cherry-pick stable linux-4.9.y commit b9dd13488acb for gcc 9 build]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I1d5a998bca751044ef2ac01e569ee500047beb0f

4 years agoturn off -Wattribute-alias 04/220804/1
Arnd Bergmann [Thu, 26 Jul 2018 08:13:22 +0000 (10:13 +0200)]
turn off -Wattribute-alias

Starting with gcc-8.1, we get a warning about all system call definitions,
which use an alias between functions with incompatible prototypes, e.g.:

In file included from ../mm/process_vm_access.c:19:
../include/linux/syscalls.h:211:18: warning: 'sys_process_vm_readv' alias between functions of incompatible types 'long int(pid_t,  const struct iovec *, long unsigned int,  const struct iovec *, long unsigned int,  long unsigned int)' {aka 'long int(int,  const struct iovec *, long unsigned int,  const struct iovec *, long unsigned int,  long unsigned int)'} and 'long int(long int,  long int,  long int,  long int,  long int,  long int)' [-Wattribute-alias]
  asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
                  ^~~
../include/linux/syscalls.h:207:2: note: in expansion of macro '__SYSCALL_DEFINEx'
  __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
  ^~~~~~~~~~~~~~~~~
../include/linux/syscalls.h:201:36: note: in expansion of macro 'SYSCALL_DEFINEx'
 #define SYSCALL_DEFINE6(name, ...) SYSCALL_DEFINEx(6, _##name, __VA_ARGS__)
                                    ^~~~~~~~~~~~~~~
../mm/process_vm_access.c:300:1: note: in expansion of macro 'SYSCALL_DEFINE6'
 SYSCALL_DEFINE6(process_vm_readv, pid_t, pid, const struct iovec __user *, lvec,
 ^~~~~~~~~~~~~~~
../include/linux/syscalls.h:215:18: note: aliased declaration here
  asmlinkage long SyS##name(__MAP(x,__SC_LONG,__VA_ARGS__)) \
                  ^~~
../include/linux/syscalls.h:207:2: note: in expansion of macro '__SYSCALL_DEFINEx'
  __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
  ^~~~~~~~~~~~~~~~~
../include/linux/syscalls.h:201:36: note: in expansion of macro 'SYSCALL_DEFINEx'
 #define SYSCALL_DEFINE6(name, ...) SYSCALL_DEFINEx(6, _##name, __VA_ARGS__)
                                    ^~~~~~~~~~~~~~~
../mm/process_vm_access.c:300:1: note: in expansion of macro 'SYSCALL_DEFINE6'
 SYSCALL_DEFINE6(process_vm_readv, pid_t, pid, const struct iovec __user *, lvec,

This is really noisy and does not indicate a real problem. In the latest
mainline kernel, this was addressed by commit bee20031772a ("disable
-Wattribute-alias warning for SYSCALL_DEFINEx()"), which seems too invasive
to backport.

This takes a much simpler approach and just disables the warning across the
kernel.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[sw0312.kim: cherry-pick stable linux-4.9.y commit b1a1d9bdb1b5 for gcc 9 build]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I930f1ed6c9350d8131e363f2feb0a73bee68007b

4 years agodrm/tgm: tdm_pp: msc: check and adjust src/dest size parameter 50/220750/1 accepted/tizen/unified/20191223.060227 submit/tizen/20191223.042319
Seung-Woo Kim [Mon, 23 Dec 2019 01:21:38 +0000 (10:21 +0900)]
drm/tgm: tdm_pp: msc: check and adjust src/dest size parameter

In msc hw, for both src and dest, image x plus image w should be
equal or less than buffer size vsize and image y plus image shou.d
be equal or less than buffer size hsize. Otherwise, hw tries to
access out of buffer boundary and it causes msc sysmmu page fault.
Fix to check and to adjust src/dest size parameter as the hw
constraint.

Change-Id: Ie6e9d431955e0c369164f2b1f46cf9f17e0b1d8b
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
4 years agousb: gadget: f_fs: Give chance to retry malloc for large size buffer 05/220605/3
Dongwoo Lee [Fri, 26 Oct 2018 01:41:41 +0000 (10:41 +0900)]
usb: gadget: f_fs: Give chance to retry malloc for large size buffer

The f_fs daemons usually use large size buffer for increasing transfer
performance, but it can cause memory allocation failure in case of
that buddy space is fragmented. Since this, instead of just returning
error in this case, give the chance to retry to allocate memory with
a half length in order to prevent daemon crash due to failure of
buffer allocation.

Change-Id: I2171932b8cb565102d63eb82c114987b85d26ed9
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
4 years agoBluetooth: Enables filter_policy and adv_type set by user 15/220215/5
Amit Purwar [Mon, 16 Dec 2019 05:58:59 +0000 (11:28 +0530)]
Bluetooth: Enables filter_policy and adv_type set by user

This patch enables the filter_policy and adv_type in advertisement
set by user on MGMT interface using set_advertising_params API.
Currently filter policy and adv_type does not get applied on slot 0
during ADV enable.

Change-Id: I18b2d5bb1db334f2f008b619503582c5eed29f08
Signed-off-by: Amit Purwar <amit.purwar@samsung.com>
4 years agoarm64: tizen_tw3_defconfig: Use configfs instead of legacy usb gadget 16/218616/1 accepted/tizen/unified/20191127.020253 submit/tizen/20191126.032220
Dongwoo Lee [Fri, 22 Nov 2019 06:16:34 +0000 (15:16 +0900)]
arm64: tizen_tw3_defconfig: Use configfs instead of legacy usb gadget

This patch replaces legacy gadget driver with configfs with CDC ACM,
rndis, functionfs support.

Change-Id: I8d96a3e95273ab830b1adf045b641024ed4a50a1
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
4 years agousb: gadget: configfs: fix concurrent issue between composite APIs 03/218603/1
Peter Chen [Mon, 26 Aug 2019 19:10:55 +0000 (15:10 -0400)]
usb: gadget: configfs: fix concurrent issue between composite APIs

[ Upstream commit 1a1c851bbd706ea9f3a9756c2d3db28523506d3b ]

We meet several NULL pointer issues if configfs_composite_unbind
and composite_setup (or composite_disconnect) are running together.
These issues occur when do the function switch stress test, the
configfs_compsoite_unbind is called from user mode by
echo "" to /sys/../UDC entry, and meanwhile, the setup interrupt
or disconnect interrupt occurs by hardware. The composite_setup
will get the cdev from get_gadget_data, but configfs_composite_unbind
will set gadget data as NULL, so the NULL pointer issue occurs.
This concurrent is hard to reproduce by native kernel, but can be
reproduced by android kernel.

In this commit, we introduce one spinlock belongs to structure
gadget_info since we can't use the same spinlock in usb_composite_dev
due to exclusive running together between composite_setup and
configfs_composite_unbind. And one bit flag 'unbind' to indicate the
code is at unbind routine, this bit is needed due to we release the
lock at during configfs_composite_unbind sometimes, and composite_setup
may be run at that time.

Several oops:

oops 1:
android_work: sent uevent USB_STATE=CONNECTED
configfs-gadget gadget: super-speed config #1: b
android_work: sent uevent USB_STATE=CONFIGURED
init: Received control message 'start' for 'adbd' from pid: 3515 (system_server)
Unable to handle kernel NULL pointer dereference at virtual address 0000002a
init: Received control message 'stop' for 'adbd' from pid: 3375 (/vendor/bin/hw/android.hardware.usb@1.1-servic)
Mem abort info:
  Exception class = DABT (current EL), IL = 32 bits
  SET = 0, FnV = 0
  EA = 0, S1PTW = 0
Data abort info:
  ISV = 0, ISS = 0x00000004
  CM = 0, WnR = 0
user pgtable: 4k pages, 48-bit VAs, pgd = ffff8008f1b7f000
[000000000000002a] *pgd=0000000000000000
Internal error: Oops: 96000004 [#1] PREEMPT SMP
Modules linked in:
CPU: 4 PID: 2457 Comm: irq/125-5b11000 Not tainted 4.14.98-07846-g0b40a9b-dirty #16
Hardware name: Freescale i.MX8QM MEK (DT)
task: ffff8008f2a98000 task.stack: ffff00000b7b8000
PC is at composite_setup+0x44/0x1508
LR is at android_setup+0xb8/0x13c
pc : [<ffff0000089ffb3c>] lr : [<ffff000008a032fc>] pstate: 800001c5
sp : ffff00000b7bbb80
x29: ffff00000b7bbb80 x28: ffff8008f2a3c010
x27: 0000000000000001 x26: 0000000000000000                                                          [1232/1897]
audit: audit_lost=25791 audit_rate_limit=5 audit_backlog_limit=64
x25: 00000000ffffffa1 x24: ffff8008f2a3c010
audit: rate limit exceeded
x23: 0000000000000409 x22: ffff000009c8e000
x21: ffff8008f7a8b428 x20: ffff00000afae000
x19: ffff0000089ff000 x18: 0000000000000000
x17: 0000000000000000 x16: ffff0000082b7c9c
x15: 0000000000000000 x14: f1866f5b952aca46
x13: e35502e30d44349c x12: 0000000000000008
x11: 0000000000000008 x10: 0000000000000a30
x9 : ffff00000b7bbd00 x8 : ffff8008f2a98a90
x7 : ffff8008f27a9c90 x6 : 0000000000000001
x5 : 0000000000000000 x4 : 0000000000000001
x3 : 0000000000000000 x2 : 0000000000000006
x1 : ffff0000089ff8d0 x0 : 732a010310b9ed00

X7: 0xffff8008f27a9c10:
9c10  00000002 00000000 00000001 00000000 13110000 ffff0000 00000002 00208040
9c30  00000000 00000000 00000000 00000000 00000000 00000005 00000029 00000000
9c50  00051778 00000001 f27a8e00 ffff8008 00000005 00000000 00000078 00000078
9c70  00000078 00000000 09031d48 ffff0000 00100000 00000000 00400000 00000000
9c90  00000001 00000000 00000000 00000000 00000000 00000000 ffefb1a0 ffff8008
9cb0  f27a9ca8 ffff8008 00000000 00000000 b9d88037 00000173 1618a3eb 00000001
9cd0  870a792a 0000002e 16188fe6 00000001 0000242b 00000000 00000000 00000000
using random self ethernet address
9cf0  019a4646 00000000 000547f3 00000000 ecfd6c33 00000002 00000000
using random host ethernet address
 00000000

X8: 0xffff8008f2a98a10:
8a10  00000000 00000000 f7788d00 ffff8008 00000001 00000000 00000000 00000000
8a30  eb218000 ffff8008 f2a98000 ffff8008 f2a98000 ffff8008 09885000 ffff0000
8a50  f34df480 ffff8008 00000000 00000000 f2a98648 ffff8008 09c8e000 ffff0000
8a70  fff2c800 ffff8008 09031d48 ffff0000 0b7bbd00 ffff0000 0b7bbd00 ffff0000
8a90  080861bc ffff0000 00000000 00000000 00000000 00000000 00000000 00000000
8ab0  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
8ad0  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
8af0  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

X21: 0xffff8008f7a8b3a8:
b3a8  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
b3c8  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
b3e8  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
b408  00000000 00000000 00000000 00000000 00000000 00000000 00000001 00000000
b428  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
b448  0053004d 00540046 00300031 00010030 eb07b520 ffff8008 20011201 00000003
b468  e418d109 0104404e 00010302 00000000 eb07b558 ffff8008 eb07b558 ffff8008
b488  f7a8b488 ffff8008 f7a8b488 ffff8008 f7a8b300 ffff8008 00000000 00000000

X24: 0xffff8008f2a3bf90:
bf90  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bfb0  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bfd0  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bff0  00000000 00000000 00000000 00000000 f76c8010 ffff8008 f76c8010 ffff8008
c010  00000000 00000000 f2a3c018 ffff8008 f2a3c018 ffff8008 08a067dc ffff0000
c030  f2a5a000 ffff8008 091c3650 ffff0000 f716fd18 ffff8008 f716fe30 ffff8008
c050  f2ce4a30 ffff8008 00000000 00000005 00000000 00000000 095d1568 ffff0000
c070  f76c8010 ffff8008 f2ce4b00 ffff8008 095cac68 ffff0000 f2a5a028 ffff8008

X28: 0xffff8008f2a3bf90:
bf90  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bfb0  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bfd0  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bff0  00000000 00000000 00000000 00000000 f76c8010 ffff8008 f76c8010 ffff8008
c010  00000000 00000000 f2a3c018 ffff8008 f2a3c018 ffff8008 08a067dc ffff0000
c030  f2a5a000 ffff8008 091c3650 ffff0000 f716fd18 ffff8008 f716fe30 ffff8008
c050  f2ce4a30 ffff8008 00000000 00000005 00000000 00000000 095d1568 ffff0000
c070  f76c8010 ffff8008 f2ce4b00 ffff8008 095cac68 ffff0000 f2a5a028 ffff8008

Process irq/125-5b11000 (pid: 2457, stack limit = 0xffff00000b7b8000)
Call trace:
Exception stack(0xffff00000b7bba40 to 0xffff00000b7bbb80)
ba40: 732a010310b9ed00 ffff0000089ff8d0 0000000000000006 0000000000000000
ba60: 0000000000000001 0000000000000000 0000000000000001 ffff8008f27a9c90
ba80: ffff8008f2a98a90 ffff00000b7bbd00 0000000000000a30 0000000000000008
baa0: 0000000000000008 e35502e30d44349c f1866f5b952aca46 0000000000000000
bac0: ffff0000082b7c9c 0000000000000000 0000000000000000 ffff0000089ff000
bae0: ffff00000afae000 ffff8008f7a8b428 ffff000009c8e000 0000000000000409
bb00: ffff8008f2a3c010 00000000ffffffa1 0000000000000000 0000000000000001
bb20: ffff8008f2a3c010 ffff00000b7bbb80 ffff000008a032fc ffff00000b7bbb80
bb40: ffff0000089ffb3c 00000000800001c5 ffff00000b7bbb80 732a010310b9ed00
bb60: ffffffffffffffff ffff0000080f777c ffff00000b7bbb80 ffff0000089ffb3c
[<ffff0000089ffb3c>] composite_setup+0x44/0x1508
[<ffff000008a032fc>] android_setup+0xb8/0x13c
[<ffff0000089bd9a8>] cdns3_ep0_delegate_req+0x44/0x70
[<ffff0000089bdff4>] cdns3_check_ep0_interrupt_proceed+0x33c/0x654
[<ffff0000089bca44>] cdns3_device_thread_irq_handler+0x4b0/0x4bc
[<ffff0000089b77b4>] cdns3_thread_irq+0x48/0x68
[<ffff000008145bf0>] irq_thread_fn+0x28/0x88
[<ffff000008145e38>] irq_thread+0x13c/0x228
[<ffff0000080fed70>] kthread+0x104/0x130
[<ffff000008085064>] ret_from_fork+0x10/0x18

oops2:
composite_disconnect: Calling disconnect on a Gadget that is                      not connected
android_work: did not send uevent (0 0           (null))
init: Received control message 'stop' for 'adbd' from pid: 3359 (/vendor/bin/hw/android.hardware.usb@1.1-service.imx)
init: Sending signal 9 to service 'adbd' (pid 22343) process group...
------------[ cut here ]------------
audit: audit_lost=180038 audit_rate_limit=5 audit_backlog_limit=64
audit: rate limit exceeded
WARNING: CPU: 0 PID: 3468 at kernel_imx/drivers/usb/gadget/composite.c:2009 composite_disconnect+0x80/0x88
Modules linked in:
CPU: 0 PID: 3468 Comm: HWC-UEvent-Thre Not tainted 4.14.98-07846-g0b40a9b-dirty #16
Hardware name: Freescale i.MX8QM MEK (DT)
task: ffff8008f2349c00 task.stack: ffff00000b0a8000
PC is at composite_disconnect+0x80/0x88
LR is at composite_disconnect+0x80/0x88
pc : [<ffff0000089ff9b0>] lr : [<ffff0000089ff9b0>] pstate: 600001c5
sp : ffff000008003dd0
x29: ffff000008003dd0 x28: ffff8008f2349c00
x27: ffff000009885018 x26: ffff000008004000
Timeout for IPC response!
x25: ffff000009885018 x24: ffff000009c8e280
x23: ffff8008f2d98010 x22: 00000000000001c0
x21: ffff8008f2d98394 x20: ffff8008f2d98010
x19: 0000000000000000 x18: 0000e3956f4f075a
fxos8700 4-001e: i2c block read acc failed
x17: 0000e395735727e8 x16: ffff00000829f4d4
x15: ffffffffffffffff x14: 7463656e6e6f6320
x13: 746f6e2009090920 x12: 7369207461687420
x11: 7465676461472061 x10: 206e6f207463656e
x9 : 6e6f637369642067 x8 : ffff000009c8e280
x7 : ffff0000086ca6cc x6 : ffff000009f15e78
x5 : 0000000000000000 x4 : 0000000000000000
x3 : ffffffffffffffff x2 : c3f28b86000c3900
x1 : c3f28b86000c3900 x0 : 000000000000004e

X20: 0xffff8008f2d97f90:
7f90  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
7fb0  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
libprocessgroup: Failed to kill process cgroup uid 0 pid 22343 in 215ms, 1 processes remain
7fd0
Timeout for IPC response!
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
using random self ethernet address
7ff0  00000000 00000000 00000000 00000000 f76c8010 ffff8008 f76c8010 ffff8008
8010  00000100 00000000 f2d98018 ffff8008 f2d98018 ffff8008 08a067dc
using random host ethernet address
 ffff0000
8030  f206d800 ffff8008 091c3650 ffff0000 f7957b18 ffff8008 f7957730 ffff8008
8050  f716a630 ffff8008 00000000 00000005 00000000 00000000 095d1568 ffff0000
8070  f76c8010 ffff8008 f716a800 ffff8008 095cac68 ffff0000 f206d828 ffff8008

X21: 0xffff8008f2d98314:
8314  ffff8008 00000000 00000000 00000000 00000000 00000000 00000000 00000000
8334  00000000 00000000 00000000 00000000 00000000 08a04cf4 ffff0000 00000000
8354  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
8374  00000000 00000000 00000000 00001001 00000000 00000000 00000000 00000000
8394  e4bbe4bb 0f230000 ffff0000 0afae000 ffff0000 ae001000 00000000 f206d400
Timeout for IPC response!
83b4  ffff8008 00000000 00000000 f7957b18 ffff8008 f7957718 ffff8008 f7957018
83d4  ffff8008 f7957118 ffff8008 f7957618 ffff8008 f7957818 ffff8008 f7957918
83f4  ffff8008 f7957d18 ffff8008 00000000 00000000 00000000 00000000 00000000

X23: 0xffff8008f2d97f90:
7f90  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
7fb0  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
7fd0  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
7ff0  00000000 00000000 00000000 00000000 f76c8010 ffff8008 f76c8010 ffff8008
8010  00000100 00000000 f2d98018 ffff8008 f2d98018 ffff8008 08a067dc ffff0000
8030  f206d800 ffff8008 091c3650 ffff0000 f7957b18 ffff8008 f7957730 ffff8008
8050  f716a630 ffff8008 00000000 00000005 00000000 00000000 095d1568 ffff0000
8070  f76c8010 ffff8008 f716a800 ffff8008 095cac68 ffff0000 f206d828 ffff8008

X28: 0xffff8008f2349b80:
9b80  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
9ba0  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
9bc0  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
9be0  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
9c00  00000022 00000000 ffffffff ffffffff 00010001 00000000 00000000 00000000
9c20  0b0a8000 ffff0000 00000002 00404040 00000000 00000000 00000000 00000000
9c40  00000001 00000000 00000001 00000000 001ebd44 00000001 f390b800 ffff8008
9c60  00000000 00000001 00000070 00000070 00000070 00000000 09031d48 ffff0000

Call trace:
Exception stack(0xffff000008003c90 to 0xffff000008003dd0)
3c80:                                   000000000000004e c3f28b86000c3900
3ca0: c3f28b86000c3900 ffffffffffffffff 0000000000000000 0000000000000000
3cc0: ffff000009f15e78 ffff0000086ca6cc ffff000009c8e280 6e6f637369642067
3ce0: 206e6f207463656e 7465676461472061 7369207461687420 746f6e2009090920
3d00: 7463656e6e6f6320 ffffffffffffffff ffff00000829f4d4 0000e395735727e8
3d20: 0000e3956f4f075a 0000000000000000 ffff8008f2d98010 ffff8008f2d98394
3d40: 00000000000001c0 ffff8008f2d98010 ffff000009c8e280 ffff000009885018
3d60: ffff000008004000 ffff000009885018 ffff8008f2349c00 ffff000008003dd0
3d80: ffff0000089ff9b0 ffff000008003dd0 ffff0000089ff9b0 00000000600001c5
3da0: ffff8008f33f2cd8 0000000000000000 0000ffffffffffff 0000000000000000
init: Received control message 'start' for 'adbd' from pid: 3359 (/vendor/bin/hw/android.hardware.usb@1.1-service.imx)
3dc0: ffff000008003dd0 ffff0000089ff9b0
[<ffff0000089ff9b0>] composite_disconnect+0x80/0x88
[<ffff000008a044d4>] android_disconnect+0x3c/0x68
[<ffff0000089ba9f8>] cdns3_device_irq_handler+0xfc/0x2c8
[<ffff0000089b84c0>] cdns3_irq+0x44/0x94
[<ffff00000814494c>] __handle_irq_event_percpu+0x60/0x24c
[<ffff000008144c0c>] handle_irq_event+0x58/0xc0
[<ffff00000814873c>] handle_fasteoi_irq+0x98/0x180
[<ffff000008143a10>] generic_handle_irq+0x24/0x38
[<ffff000008144170>] __handle_domain_irq+0x60/0xac
[<ffff0000080819c4>] gic_handle_irq+0xd4/0x17c

Signed-off-by: Peter Chen <peter.chen@nxp.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[dwoo08.lee: cherry-pick linux-4.9.y stable commit 59682e70c980 and resolve conflicts to stablize configfs]
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
Change-Id: I891e07b46cb1783e5f1c7a1c5a6198bb62611b20

4 years agousb: gadget: configs: plug memory leak 02/218602/1
John Keeping [Tue, 28 Feb 2017 10:55:30 +0000 (10:55 +0000)]
usb: gadget: configs: plug memory leak

[ Upstream commit 38355b2a44776c25b0f2ad466e8c51bb805b3032 ]

When binding a gadget to a device, "name" is stored in gi->udc_name, but
this does not happen when unregistering and the string is leaked.

Signed-off-by: John Keeping <john@metanate.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[dwoo08.lee: cherry-pick linux-4.9.y stable commit 59682e70c980 to stablize configfs]
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
Change-Id: Ieb2bcfeed245a0b993ac6c4992af8fe27fc89d48

4 years agousb: gadget: Zero ffs_io_data 00/218600/1
Andrzej Pietrasiewicz [Mon, 3 Jun 2019 17:05:28 +0000 (19:05 +0200)]
usb: gadget: Zero ffs_io_data

[ Upstream commit 508595515f4bcfe36246e4a565cf280937aeaade ]

In some cases the "Allocate & copy" block in ffs_epfile_io() is not
executed. Consequently, in such a case ffs_alloc_buffer() is never called
and struct ffs_io_data is not initialized properly. This in turn leads to
problems when ffs_free_buffer() is called at the end of ffs_epfile_io().

This patch uses kzalloc() instead of kmalloc() in the aio case and memset()
in non-aio case to properly initialize struct ffs_io_data.

Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[dwoo08.lee: cherry-pick linux-4.9.y stable commit d585589e5f9b to stablize f_fs]
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
Change-Id: I33ef7d5123301beb94b9d8530664d861464f4bb1

4 years agousb: f_fs: Avoid crash due to out-of-scope stack ptr access 99/218599/1
John Stultz [Tue, 5 Feb 2019 18:24:40 +0000 (10:24 -0800)]
usb: f_fs: Avoid crash due to out-of-scope stack ptr access

[ Upstream commit 54f64d5c983f939901dacc8cfc0983727c5c742e ]

Since the 5.0 merge window opened, I've been seeing frequent
crashes on suspend and reboot with the trace:

[   36.911170] Unable to handle kernel paging request at virtual address ffffff801153d660
[   36.912769] Unable to handle kernel paging request at virtual address ffffff800004b564
...
[   36.950666] Call trace:
[   36.950670]  queued_spin_lock_slowpath+0x1cc/0x2c8
[   36.950681]  _raw_spin_lock_irqsave+0x64/0x78
[   36.950692]  complete+0x28/0x70
[   36.950703]  ffs_epfile_io_complete+0x3c/0x50
[   36.950713]  usb_gadget_giveback_request+0x34/0x108
[   36.950721]  dwc3_gadget_giveback+0x50/0x68
[   36.950723]  dwc3_thread_interrupt+0x358/0x1488
[   36.950731]  irq_thread_fn+0x30/0x88
[   36.950734]  irq_thread+0x114/0x1b0
[   36.950739]  kthread+0x104/0x130
[   36.950747]  ret_from_fork+0x10/0x1c

I isolated this down to in ffs_epfile_io():
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/gadget/function/f_fs.c#n1065

Where the completion done is setup on the stack:
  DECLARE_COMPLETION_ONSTACK(done);

Then later we setup a request and queue it, and wait for it:
  if (unlikely(wait_for_completion_interruptible(&done))) {
    /*
    * To avoid race condition with ffs_epfile_io_complete,
    * dequeue the request first then check
    * status. usb_ep_dequeue API should guarantee no race
    * condition with req->complete callback.
    */
    usb_ep_dequeue(ep->ep, req);
    interrupted = ep->status < 0;
  }

The problem is, that we end up being interrupted, dequeue the
request, and exit.

But then the irq triggers and we try calling complete() on the
context pointer which points to now random stack space, which
results in the panic.

Alan Stern pointed out there is a bug here, in that the snippet
above "assumes that usb_ep_dequeue() waits until the request has
been completed." And that:

    wait_for_completion(&done);

Is needed right after the usb_ep_dequeue().

Thus this patch implements that change. With it I no longer see
the crashes on suspend or reboot.

This issue seems to have been uncovered by behavioral changes in
the dwc3 driver in commit fec9095bdef4e ("usb: dwc3: gadget:
remove wait_end_transfer").

Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Felipe Balbi <balbi@kernel.org>
Cc: Zeng Tao <prime.zeng@hisilicon.com>
Cc: Jack Pham <jackp@codeaurora.org>
Cc: Thinh Nguyen <thinh.nguyen@synopsys.com>
Cc: Chen Yu <chenyu56@huawei.com>
Cc: Jerry Zhang <zhangjerry@google.com>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Vincent Pelletier <plr.vincent@gmail.com>
Cc: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Linux USB List <linux-usb@vger.kernel.org>
Suggested-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[dwoo08.lee: cherry-pick linux-4.9.y stable commit 49145924e804 to stablize f_fs]
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
Change-Id: I5a786991ea9ceef96ff6c6b65dc807f842356fd6

4 years agousb: gadget: f_fs: Only return delayed status when len is 0 98/218598/1
Jerry Zhang [Mon, 2 Jul 2018 19:48:08 +0000 (12:48 -0700)]
usb: gadget: f_fs: Only return delayed status when len is 0

commit 4d644abf25698362bd33d17c9ddc8f7122c30f17 upstream.

Commit 1b9ba000 ("Allow function drivers to pause control
transfers") states that USB_GADGET_DELAYED_STATUS is only
supported if data phase is 0 bytes.

It seems that when the length is not 0 bytes, there is no
need to explicitly delay the data stage since the transfer
is not completed until the user responds. However, when the
length is 0, there is no data stage and the transfer is
finished once setup() returns, hence there is a need to
explicitly delay completion.

This manifests as the following bugs:

Prior to 946ef68ad4e4 ('Let setup() return
USB_GADGET_DELAYED_STATUS'), when setup is 0 bytes, ffs
would require user to queue a 0 byte request in order to
clear setup state. However, that 0 byte request was actually
not needed and would hang and cause errors in other setup
requests.

After the above commit, 0 byte setups work since the gadget
now accepts empty queues to ep0 to clear the delay, but all
other setups hang.

Fixes: 946ef68ad4e4 ("Let setup() return USB_GADGET_DELAYED_STATUS")
Signed-off-by: Jerry Zhang <zhangjerry@google.com>
Cc: stable <stable@vger.kernel.org>
Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[dwoo08.lee: cherry-pick linux-4.9.y stable commit 9e10043b6bdc to stablize f_fs]
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
Change-Id: Idf5d504bd5059cc5141f4a3e98c572708c631079

4 years agousb: gadget: ffs: Execute copy_to_user() with USER_DS set 97/218597/1
Lars-Peter Clausen [Fri, 12 Jan 2018 10:05:02 +0000 (11:05 +0100)]
usb: gadget: ffs: Execute copy_to_user() with USER_DS set

[ Upstream commit 4058ebf33cb0be88ca516f968eda24ab7b6b93e4 ]

When using a AIO read() operation on the function FS gadget driver a URB is
submitted asynchronously and on URB completion the received data is copied
to the userspace buffer associated with the read operation.

This is done from a kernel worker thread invoking copy_to_user() (through
copy_to_iter()). And while the user space process memory is made available
to the kernel thread using use_mm(), some architecture require in addition
to this that the operation runs with USER_DS set. Otherwise the userspace
memory access will fail.

For example on ARM64 with Privileged Access Never (PAN) and User Access
Override (UAO) enabled the following crash occurs.

Internal error: Accessing user space memory with fs=KERNEL_DS: 9600004f [#1] SMP
Modules linked in:
CPU: 2 PID: 1636 Comm: kworker/2:1 Not tainted 4.9.0-04081-g8ab2dfb-dirty #487
Hardware name: ZynqMP ZCU102 Rev1.0 (DT)
Workqueue: events ffs_user_copy_worker
task: ffffffc87afc8080 task.stack: ffffffc87a00c000
PC is at __arch_copy_to_user+0x190/0x220
LR is at copy_to_iter+0x78/0x3c8
[...]
[<ffffff800847b790>] __arch_copy_to_user+0x190/0x220
[<ffffff80086f25d8>] ffs_user_copy_worker+0x70/0x130
[<ffffff80080b8c64>] process_one_work+0x1dc/0x460
[<ffffff80080b8f38>] worker_thread+0x50/0x4b0
[<ffffff80080bf5a0>] kthread+0xd8/0xf0
[<ffffff8008083680>] ret_from_fork+0x10/0x50

Address this by placing a set_fs(USER_DS) before of the copy operation
and revert it again once the copy operation has finished.

This patch is analogous to commit d7ffde35e31a ("vhost: use USER_DS in
vhost_worker thread") which addresses the same underlying issue.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[dwoo08.lee: cherry-pick linux-4.9.y stable commit 5209c778346a to stablize f_fs]
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
Change-Id: Iee47b31c16c2f83540e4e1f8bd3f3eaebd727ad2

4 years agousb: gadget: ffs: Let setup() return USB_GADGET_DELAYED_STATUS 96/218596/1
Lars-Peter Clausen [Fri, 12 Jan 2018 10:26:16 +0000 (11:26 +0100)]
usb: gadget: ffs: Let setup() return USB_GADGET_DELAYED_STATUS

[ Upstream commit 946ef68ad4e45aa048a5fb41ce8823ed29da866a ]

Some UDC drivers (like the DWC3) expect that the response to a setup()
request is queued from within the setup function itself so that it is
available as soon as setup() has completed.

Upon receiving a setup request the function fs driver creates an event that
is made available to userspace. And only once userspace has acknowledged
that event the response to the setup request is queued.

So it violates the requirement of those UDC drivers and random failures can
be observed. This is basically a race condition and if userspace is able to
read the event and queue the response fast enough all is good. But if it is
not, for example because other processes are currently scheduled to run,
the USB host that sent the setup request will observe an error.

To avoid this the gadget framework provides the USB_GADGET_DELAYED_STATUS
return code. If a setup() callback returns this value the UDC driver is
aware that response is not yet available and can uses the appropriate
methods to handle this case.

Since in the case of function fs the response will never be available when
the setup() function returns make sure that this status code is used.

This fixed random occasional failures that were previously observed on a
DWC3 based system under high system load.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[dwoo08.lee: cherry-pick linux-4.9.y stable commit 10be2659c629 to stablize f_fs]
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
Change-Id: I1b88c4739c9007bfd515b670401035ef2bc541fc

4 years agousb: gadget: f_fs: Fix use-after-free in ffs_fs_kill_sb() 95/218595/1
Xinyong [Fri, 2 Mar 2018 11:20:07 +0000 (19:20 +0800)]
usb: gadget: f_fs: Fix use-after-free in ffs_fs_kill_sb()

commit 1a087f032111a88e826877449dfb93ceb22b78b9 upstream.

When I debug a kernel crash issue in funcitonfs, found ffs_data.ref
overflowed, While functionfs is unmounting, ffs_data is put twice.

Commit 43938613c6fd ("drivers, usb: convert ffs_data.ref from atomic_t to
refcount_t") can avoid refcount overflow, but that is risk some situations.
So no need put ffs data in ffs_fs_kill_sb, already put in ffs_data_closed.

The issue can be reproduced in Mediatek mt6763 SoC, ffs for ADB device.
KASAN enabled configuration reports use-after-free errro.

BUG: KASAN: use-after-free in refcount_dec_and_test+0x14/0xe0 at addr ffffffc0579386a0
Read of size 4 by task umount/4650
====================================================
BUG kmalloc-512 (Tainted: P        W  O   ): kasan: bad access detected
-----------------------------------------------------------------------------

INFO: Allocated in ffs_fs_mount+0x194/0x844 age=22856 cpu=2 pid=566
    alloc_debug_processing+0x1ac/0x1e8
    ___slab_alloc.constprop.63+0x640/0x648
    __slab_alloc.isra.57.constprop.62+0x24/0x34
    kmem_cache_alloc_trace+0x1a8/0x2bc
    ffs_fs_mount+0x194/0x844
    mount_fs+0x6c/0x1d0
    vfs_kern_mount+0x50/0x1b4
    do_mount+0x258/0x1034
INFO: Freed in ffs_data_put+0x25c/0x320 age=0 cpu=3 pid=4650
    free_debug_processing+0x22c/0x434
    __slab_free+0x2d8/0x3a0
    kfree+0x254/0x264
    ffs_data_put+0x25c/0x320
    ffs_data_closed+0x124/0x15c
    ffs_fs_kill_sb+0xb8/0x110
    deactivate_locked_super+0x6c/0x98
    deactivate_super+0xb0/0xbc
INFO: Object 0xffffffc057938600 @offset=1536 fp=0x          (null)
......
Call trace:
[<ffffff900808cf5c>] dump_backtrace+0x0/0x250
[<ffffff900808d3a0>] show_stack+0x14/0x1c
[<ffffff90084a8c04>] dump_stack+0xa0/0xc8
[<ffffff900826c2b4>] print_trailer+0x158/0x260
[<ffffff900826d9d8>] object_err+0x3c/0x40
[<ffffff90082745f0>] kasan_report_error+0x2a8/0x754
[<ffffff9008274f84>] kasan_report+0x5c/0x60
[<ffffff9008273208>] __asan_load4+0x70/0x88
[<ffffff90084cd81c>] refcount_dec_and_test+0x14/0xe0
[<ffffff9008d98f9c>] ffs_data_put+0x80/0x320
[<ffffff9008d9d904>] ffs_fs_kill_sb+0xc8/0x110
[<ffffff90082852a0>] deactivate_locked_super+0x6c/0x98
[<ffffff900828537c>] deactivate_super+0xb0/0xbc
[<ffffff90082af0c0>] cleanup_mnt+0x64/0xec
[<ffffff90082af1b0>] __cleanup_mnt+0x10/0x18
[<ffffff90080d9e68>] task_work_run+0xcc/0x124
[<ffffff900808c8c0>] do_notify_resume+0x60/0x70
[<ffffff90080866e4>] work_pending+0x10/0x14

Cc: stable@vger.kernel.org
Signed-off-by: Xinyong <xinyong.fang@linux.alibaba.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[dwoo08.lee: cherry-pick linux-4.9.y stable commit dddf4650cf64 to stablize f_fs]
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
Change-Id: I32845cb6181c82662c8873505c2d9aff3f3f980c

4 years agousb: gadget: f_fs: Process all descriptors during bind 94/218594/1
Jack Pham [Wed, 24 Jan 2018 08:11:53 +0000 (00:11 -0800)]
usb: gadget: f_fs: Process all descriptors during bind

commit 6cf439e0d37463e42784271179c8a308fd7493c6 upstream.

During _ffs_func_bind(), the received descriptors are evaluated
to prepare for binding with the gadget in order to allocate
endpoints and optionally set up OS descriptors. However, the
high- and super-speed descriptors are only parsed based on
whether the gadget_is_dualspeed() and gadget_is_superspeed()
calls are true, respectively.

This is a problem in case a userspace program always provides
all of the {full,high,super,OS} descriptors when configuring a
function. Then, for example if a gadget device is not capable
of SuperSpeed, the call to ffs_do_descs() for the SS descriptors
is skipped, resulting in an incorrect offset calculation for
the vla_ptr when moving on to the OS descriptors that follow.
This causes ffs_do_os_descs() to fail as it is now looking at
the SS descriptors' offset within the raw_descs buffer instead.

_ffs_func_bind() should evaluate the descriptors unconditionally,
so remove the checks for gadget speed.

Fixes: f0175ab51993 ("usb: gadget: f_fs: OS descriptors support")
Cc: stable@vger.kernel.org
Co-Developed-by: Mayank Rana <mrana@codeaurora.org>
Signed-off-by: Mayank Rana <mrana@codeaurora.org>
Signed-off-by: Jack Pham <jackp@codeaurora.org>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[dwoo08.lee: cherry-pick linux-4.9.y stable commit 8bedacf13d59 to stablize f_fs]
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
Change-Id: I0ed8330a0e692ea80263f31b7804203edfbd2d4d

4 years agousb: f_fs: Prevent gadget unbind if it is already unbound 93/218593/1
Hemant Kumar [Tue, 9 Jan 2018 07:00:53 +0000 (12:30 +0530)]
usb: f_fs: Prevent gadget unbind if it is already unbound

commit ce5bf9a50daf2d9078b505aca1cea22e88ecb94a upstream.

Upon usb composition switch there is possibility of ep0 file
release happening after gadget driver bind. In case of composition
switch from adb to a non-adb composition gadget will never gets
bound again resulting into failure of usb device enumeration. Fix
this issue by checking FFS_FL_BOUND flag and avoid extra
gadget driver unbind if it is already done as part of composition
switch.

This fixes adb reconnection error reported on Android running
v4.4 and above kernel versions. Verified on Hikey running vanilla
v4.15-rc7 + few out of tree Mali patches.

Reviewed-at: https://android-review.googlesource.com/#/c/582632/

Cc: Felipe Balbi <balbi@kernel.org>
Cc: Greg KH <gregkh@linux-foundation.org>
Cc: Michal Nazarewicz <mina86@mina86.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Dmitry Shmidt <dimitrysh@google.com>
Cc: Badhri <badhri@google.com>
Cc: Android Kernel Team <kernel-team@android.com>
Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>
[AmitP: Cherry-picked it from android-4.14 and updated the commit log]
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[dwoo08.lee: cherry-pick linux-4.9.y stable commit f24d171a8100 to stablize f_fs]
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
Change-Id: Ifbab9f182fa3779c57ab288958553c3711d50e28

4 years agousb: gadget: ffs: Forbid usb_ep_alloc_request from sleeping 92/218592/1
Vincent Pelletier [Sun, 26 Nov 2017 06:52:53 +0000 (06:52 +0000)]
usb: gadget: ffs: Forbid usb_ep_alloc_request from sleeping

commit 30bf90ccdec1da9c8198b161ecbff39ce4e5a9ba upstream.

Found using DEBUG_ATOMIC_SLEEP while submitting an AIO read operation:

[  100.853642] BUG: sleeping function called from invalid context at mm/slab.h:421
[  100.861148] in_atomic(): 1, irqs_disabled(): 1, pid: 1880, name: python
[  100.867954] 2 locks held by python/1880:
[  100.867961]  #0:  (&epfile->mutex){....}, at: [<f8188627>] ffs_mutex_lock+0x27/0x30 [usb_f_fs]
[  100.868020]  #1:  (&(&ffs->eps_lock)->rlock){....}, at: [<f818ad4b>] ffs_epfile_io.isra.17+0x24b/0x590 [usb_f_fs]
[  100.868076] CPU: 1 PID: 1880 Comm: python Not tainted 4.14.0-edison+ #118
[  100.868085] Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542 2015.01.21:18.19.48
[  100.868093] Call Trace:
[  100.868122]  dump_stack+0x47/0x62
[  100.868156]  ___might_sleep+0xfd/0x110
[  100.868182]  __might_sleep+0x68/0x70
[  100.868217]  kmem_cache_alloc_trace+0x4b/0x200
[  100.868248]  ? dwc3_gadget_ep_alloc_request+0x24/0xe0 [dwc3]
[  100.868302]  dwc3_gadget_ep_alloc_request+0x24/0xe0 [dwc3]
[  100.868343]  usb_ep_alloc_request+0x16/0xc0 [udc_core]
[  100.868386]  ffs_epfile_io.isra.17+0x444/0x590 [usb_f_fs]
[  100.868424]  ? _raw_spin_unlock_irqrestore+0x27/0x40
[  100.868457]  ? kiocb_set_cancel_fn+0x57/0x60
[  100.868477]  ? ffs_ep0_poll+0xc0/0xc0 [usb_f_fs]
[  100.868512]  ffs_epfile_read_iter+0xfe/0x157 [usb_f_fs]
[  100.868551]  ? security_file_permission+0x9c/0xd0
[  100.868587]  ? rw_verify_area+0xac/0x120
[  100.868633]  aio_read+0x9d/0x100
[  100.868692]  ? __fget+0xa2/0xd0
[  100.868727]  ? __might_sleep+0x68/0x70
[  100.868763]  SyS_io_submit+0x471/0x680
[  100.868878]  do_int80_syscall_32+0x4e/0xd0
[  100.868921]  entry_INT80_32+0x2a/0x2a
[  100.868932] EIP: 0xb7fbb676
[  100.868941] EFLAGS: 00000292 CPU: 1
[  100.868951] EAX: ffffffda EBX: b7aa2000 ECX: 00000002 EDX: b7af8368
[  100.868961] ESI: b7fbb660 EDI: b7aab000 EBP: bfb6c658 ESP: bfb6c638
[  100.868973]  DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b

Signed-off-by: Vincent Pelletier <plr.vincent@gmail.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[dwoo08.lee: cherry-pick linux-4.9.y stable commit 16648cbcd332 to stablize f_fs]
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
Change-Id: I7716588e2a674be3f5f602273fd283273b87b730

4 years agousb: f_fs: Force Reserved1=1 in OS_DESC_EXT_COMPAT 91/218591/1
John Keeping [Mon, 27 Nov 2017 18:15:40 +0000 (18:15 +0000)]
usb: f_fs: Force Reserved1=1 in OS_DESC_EXT_COMPAT

commit a3acc696085e112733d191a77b106e67a4fa110b upstream.

The specification says that the Reserved1 field in OS_DESC_EXT_COMPAT
must have the value "1", but when this feature was first implemented we
rejected any non-zero values.

This was adjusted to accept all non-zero values (while now rejecting
zero) in commit 53642399aa71 ("usb: gadget: f_fs: Fix wrong check on
reserved1 of OS_DESC_EXT_COMPAT"), but that breaks any userspace
programs that worked previously by returning EINVAL when Reserved1 == 0
which was previously the only value that succeeded!

If we just set the field to "1" ourselves, both old and new userspace
programs continue to work correctly and, as a bonus, old programs are
now compliant with the specification without having to fix anything
themselves.

Fixes: 53642399aa71 ("usb: gadget: f_fs: Fix wrong check on reserved1 of OS_DESC_EXT_COMPAT")
Signed-off-by: John Keeping <john@metanate.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[dwoo08.lee: cherry-pick linux-4.9.y stable commit 112b8a8f558d to stablize f_fs]
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
Change-Id: I00f7fce7bc2c5225c3f9ec00f30d1e4f4f0582de

4 years agousb: gadget: f_fs: Fix ExtCompat descriptor validation 90/218590/1
Vincent Pelletier [Thu, 15 Dec 2016 12:47:42 +0000 (12:47 +0000)]
usb: gadget: f_fs: Fix ExtCompat descriptor validation

[ Upstream commit 354bc45bf329494ef6051f3229ef50b9e2a7ea2a ]

Reserved1 is documented as expected to be set to 0, but this test fails
when it it set to 0. Reverse the condition.

Signed-off-by: Vincent Pelletier <plr.vincent@gmail.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[dwoo08.lee: cherry-pick linux-4.9.y stable commit 5eb97be87981 to stablize f_fs]
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
Change-Id: Id8bd89a9cb5343fd0830d480ad5b2900367d8056

4 years agousb: gadget: f_fs: Fix use-after-free in ffs_free_inst 89/218589/1
Andrew Gabbasov [Wed, 8 Nov 2017 17:13:15 +0000 (10:13 -0700)]
usb: gadget: f_fs: Fix use-after-free in ffs_free_inst

commit cdafb6d8b8da7fde266f79b3287ac221aa841879 upstream.

KASAN enabled configuration reports an error

BUG: KASAN: use-after-free in ffs_free_inst+... [usb_f_fs] at addr ...
Write of size 8 by task ...

This is observed after "ffs-test" is run and interrupted. If after that
functionfs is unmounted and g_ffs module is unloaded, that use-after-free
occurs during g_ffs module removal.

Although the report indicates ffs_free_inst() function, the actual
use-after-free condition occurs in _ffs_free_dev() function, which
is probably inlined into ffs_free_inst().

This happens due to keeping the ffs_data reference in device structure
during functionfs unmounting, while ffs_data itself is freed as no longer
needed. The fix is to clear that reference in ffs_closed() function,
which is a counterpart of ffs_ready(), where the reference is stored.

Fixes: 3262ad824307 ("usb: gadget: f_fs: Stop ffs_closed NULL pointer dereference")
Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com>
Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[dwoo08.lee: cherry-pick linux-4.9.y stable commit fd6a742d8bf7 to stablize f_fs]
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
Change-Id: I6e32305fee754d8a11eaa0650319e8e620d4c2af

4 years ago[LOCAL] arm64/ptrace: Add compat FPR register support 37/218037/2 accepted/tizen/unified/20191121.154757 submit/tizen/20191121.072817
Seung-Woo Kim [Tue, 19 Nov 2019 01:21:01 +0000 (10:21 +0900)]
[LOCAL] arm64/ptrace: Add compat FPR register support

From aarch32 ptrace view, fpr register support is done with vfp
registers. As like aarch32 ptrace view, Add to suppot compat fpr
resister with vfp.

Change-Id: If5b4b6b5f33b7691ba9d3b65c1bffcf316e19588
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
4 years ago[LOCAL] arm64: perf: Report arm pc registers for compat perf 36/218036/2
Seung-Woo Kim [Wed, 11 Dec 2019 00:57:56 +0000 (09:57 +0900)]
[LOCAL] arm64: perf: Report arm pc registers for compat perf

If perf is built as arm 32-bit, it only reads 15 registers as arm
32-bit register map and this breaks dwarf call-chain in compat
perf because pc register information is not filled.
Report arm pc registers for 32-bit compat perf.

Without this, arm 32-bit perf dwarf call-graph shows below
verbose message:
  unwind: reg 15, val 0
  unwind: reg 13, val ffbc6360
  unwind: no map for 0

Posted to mainline[1] but never merged.

[1]: https://patchwork.kernel.org/patch/11238463/
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I8c35067224707b3077d7bfd14efda7c20c8d2869

4 years agoarm64: ftrace: don't adjust the LR value 71/218071/1
Mark Rutland [Thu, 15 Nov 2018 22:42:01 +0000 (22:42 +0000)]
arm64: ftrace: don't adjust the LR value

[ Upstream commit 6e803e2e6e367db9a0d6ecae1bd24bb5752011bd ]

The core ftrace code requires that when it is handed the PC of an
instrumented function, this PC is the address of the instrumented
instruction. This is necessary so that the core ftrace code can identify
the specific instrumentation site. Since the instrumented function will
be a BL, the address of the instrumented function is LR - 4 at entry to
the ftrace code.

This fixup is applied in the mcount_get_pc and mcount_get_pc0 helpers,
which acquire the PC of the instrumented function.

The mcount_get_lr helper is used to acquire the LR of the instrumented
function, whose value does not require this adjustment, and cannot be
adjusted to anything meaningful. No adjustment of this value is made on
other architectures, including arm. However, arm64 adjusts this value by
4.

This patch brings arm64 in line with other architectures and removes the
adjustment of the LR value.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Torsten Duwe <duwe@suse.de>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[sw0312.kim: cherry-pick linux-4.9.y stable commit bfadca610fcf to fix ftrace issue]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: Ib9a2bd4728efeb0b1fa28e60135ba596bac55ace

4 years agoarm64: Fix static use of function graph 70/218070/1
Julien Thierry [Fri, 3 Nov 2017 11:44:16 +0000 (11:44 +0000)]
arm64: Fix static use of function graph

Function graph does not work currently when CONFIG_DYNAMIC_TRACE is not
set. This is because ftrace_function_trace is not always set to ftrace_stub
when function_graph is in use.

Do not skip checking of graph tracer functions when ftrace_function_trace
is set.

Signed-off-by: Julien Thierry <julien.thierry@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Reviewed-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
[sw0312.kim: cherry-pick mainline commit d125bffcefb2 to fix function_graph without CONFIG_DYNAMIC_TRACE]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I7eddd61e45ed2f459bd70785126eaf551ee7a3d2

4 years agoarm64: include asm/assembler.h in entry-ftrace.S 69/218069/1
Arnd Bergmann [Tue, 14 Feb 2017 21:32:58 +0000 (22:32 +0100)]
arm64: include asm/assembler.h in entry-ftrace.S

In a randconfig build I ran into this build error:

arch/arm64/kernel/entry-ftrace.S: Assembler messages:
arch/arm64/kernel/entry-ftrace.S:101: Error: unknown mnemonic `ldr_l' -- `ldr_l x2,ftrace_trace_function'

The macro is defined in asm/assembler.h, so we should include that file.

Fixes: 829d2bd13392 ("arm64: entry-ftrace.S: avoid open-coded {adr,ldr}_l")
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Will Deacon <will.deacon@arm.com>
[sw0312.kim: cherry-pick mainline commit f705d954634d to apply function_graph related patch]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: Ifeb122550ece026c45bd5509f0ba86adb0228e24

4 years agoarm64: entry-ftrace.S: avoid open-coded {adr,ldr}_l 68/218068/1
Mark Rutland [Tue, 17 Jan 2017 16:10:58 +0000 (16:10 +0000)]
arm64: entry-ftrace.S: avoid open-coded {adr,ldr}_l

Some places in the kernel open-code sequences using ADRP for a symbol
another instruction using a :lo12: relocation for that same symbol.
These sequences are easy to get wrong, and more painful to read than is
necessary. For these reasons, it is preferable to use the
{adr,ldr,str}_l macros for these cases.

This patch makes use of these in entry-ftrace.S, removing open-coded
sequences using adrp. This results in a minor code change, since a
temporary register is not used when generating the address for some
symbols, but this is fine, as the value of the temporary register is not
used elsewhere.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
[sw0312.kim: cherry-pick mainline commit 829d2bd13392 to apply function_graph related patch]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I72fa3cbcf569f679b13f436b35793e69725849d4

4 years agoarm64: tizen_tw3_defconfig: Enable FTRACE 18/216718/4
Seung-Woo Kim [Thu, 31 Oct 2019 05:21:14 +0000 (14:21 +0900)]
arm64: tizen_tw3_defconfig: Enable FTRACE

Enable FTRACE with FUNCTION_TRACE and FUNCION_GRAHPIC_TRACER for
config options to support function trace.

Change-Id: I5617579549cd8e1579e076a92e4a4bb11a2878dc
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
4 years agoarm64: make secondary_start_kernel() notrace 99/217799/2
Zhizhou Zhang [Tue, 12 Jun 2018 09:07:37 +0000 (17:07 +0800)]
arm64: make secondary_start_kernel() notrace

[ Upstream commit b154886f7892499d0d3054026e19dfb9a731df61 ]

We can't call function trace hook before setup percpu offset.
When entering secondary_start_kernel(), percpu offset has not
been initialized.  So this lead hotplug malfunction.
Here is the flow to reproduce this bug:

echo 0 > /sys/devices/system/cpu/cpu1/online
echo function > /sys/kernel/debug/tracing/current_tracer
echo 1 > /sys/kernel/debug/tracing/tracing_on
echo 1 > /sys/devices/system/cpu/cpu1/online

Acked-by: Mark Rutland <mark.rutland@arm.com>
Tested-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Zhizhou Zhang <zhizhouzhang@asrmicro.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[sw0312.kim: apply stable linux-4.9.y commit 40137ff99323 to fix ftrace issue]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I1bb45adfe88a4284561cde6d1a1bb31951a2d677

4 years agostaging: samsung: add build dependency for SEC_DUMP_SUMMARY to SEC_DEBUG 86/217786/1
Seung-Woo Kim [Thu, 14 Nov 2019 07:22:44 +0000 (16:22 +0900)]
staging: samsung: add build dependency for SEC_DUMP_SUMMARY to SEC_DEBUG

The SEC_DUMP_SUMMARY is inside of sec_debug driver, so the option
should be dependent on SEC_DEBUG. Add the build dependency.

Change-Id: I4a0d338e27c29f4d01c84435d69099f17fbb7ef1
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
4 years agowatchdog: s3c2410: Fix build issue without EXYNOS_SNAPSHOT 85/217785/1
Seung-Woo Kim [Thu, 14 Nov 2019 07:28:43 +0000 (16:28 +0900)]
watchdog: s3c2410: Fix build issue without EXYNOS_SNAPSHOT

The watchdog driver can be used without CONFIG_EXYNOS_SNAPSHOT,
but some s3c watchdog functions are dependent on the config.
Fix build issue without CONFIG_EXYNOS_SNAPSHOT.

Change-Id: I9f846c99fc5a7dfea95c5e4835dcf1336d8cf7e9
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
4 years agosensorhub: Fix input notify dependency to SEC_DEBUG 84/217784/1
Seung-Woo Kim [Thu, 14 Nov 2019 07:31:38 +0000 (16:31 +0900)]
sensorhub: Fix input notify dependency to SEC_DEBUG

The input notify can be used outside of SEC_DEBUG, but its enum is
defiend inside of SEC_DEBUG. Fix the input notify dependency to
SEC_DEBUG.

Change-Id: Iabec8761f23404e6c08436b07a149ea7b760827a
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
4 years agosensorhub: remove unused variable without SSP_SEC_DEBUG option 83/217783/1
Seung-Woo Kim [Thu, 14 Nov 2019 07:24:59 +0000 (16:24 +0900)]
sensorhub: remove unused variable without SSP_SEC_DEBUG option

If not using SSP_SEC_DEBUG, there is unused variable backup_fs.
Remove the unused variable.

Change-Id: Ib64f940e9a3c5080eb75255a218c01eb09373588
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
4 years agoarm64: tizen_tw3_defconfig: Enable CONFIG_CRYPTO_USER_API 14/217614/1 accepted/tizen/unified/20191113.123430 submit/tizen/20191113.062026
DoHyun Pyun [Wed, 13 Nov 2019 04:26:44 +0000 (13:26 +0900)]
arm64: tizen_tw3_defconfig: Enable CONFIG_CRYPTO_USER_API

Enable CONFIG_CRYPTO_USER_API config options to use CRYPTO
API from userspace. ALG(Algorithm) socket will be used for
BLE Mesh functionality by bluez.

Change-Id: Iaa07610176bba04a301449fdee5446f36124eb3e
Signed-off-by: DoHyun Pyun <dh79.pyun@samsung.com>
4 years agoBluetooth: Do not update background scan when updating connectable 29/217529/1
Deokhyun Kim [Tue, 12 Nov 2019 07:44:09 +0000 (16:44 +0900)]
Bluetooth: Do not update background scan when updating connectable

Scan should be kept even though connectable is changed, because it may not be
a scan for connection.

Change-Id: I87b5d76c86c786de712dad4c801e8642d8cd885a
Signed-off-by: Deokhyun Kim <dukan.kim@samsung.com>
4 years agoInput: s2mpw02-power-key: support back key boost 15/216715/1 accepted/tizen/unified/20191106.124703 submit/tizen/20191106.012900
Seung-Woo Kim [Thu, 31 Oct 2019 02:29:13 +0000 (11:29 +0900)]
Input: s2mpw02-power-key: support back key boost

Now, keymap can be changed and it is mainly for using back key
instead of power key. So as like gpio-keys, it needs to consider
back key boost. Support back key boost like gpio-keys.

Change-Id: I22826afcbbe3ba933a63e9f9106f8d05e3767f3b
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
4 years agoInput: s2mpw02-power-key: support setkeycode 14/216714/1
Seung-Woo Kim [Thu, 31 Oct 2019 01:39:31 +0000 (10:39 +0900)]
Input: s2mpw02-power-key: support setkeycode

Add support for input_setkeycode to the s2mpw02-power-key driver
for using the udev hwdb mechanism to change keymap.

Change-Id: I581c12ae32595b04b90c4685d9fa0a6aed501f2f
Reference: 4b17f91b1677 ("Input: gpio-keys - add support for setkeycode")
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
4 years agoInput: gpio-keys - add support for setkeycode 13/216713/1
Hans de Goede [Thu, 31 Oct 2019 01:39:13 +0000 (10:39 +0900)]
Input: gpio-keys - add support for setkeycode

gpio-keys input devices created by the soc_button_array driver are
configured with key-codes based on ACPI provided information.

Unfortunately on some tablets this info is wrong, and we need to have
a quirk to fix things up.

Add support for input_setkeycode to the gpio-keys driver, so that
the existing udev hwdb mechanism can be used to fix things up on these
tablets.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
[sw0312.kim: backport mainline commit 83e4947a569f to suuport setkeycode]
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=83e4947a569f4d544ef4a1361f51c91d73a9c915
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: Ia21dbdb9591b7a83989dfcba561eb5a4cf846ade

4 years agosoc: samsung: cal-if: exynos9110: remove clocks for secure world 47/216247/3 tizen_5.5_tv accepted/tizen/5.5/unified/20191115.093732 accepted/tizen/unified/20191101.042028 submit/tizen/20191031.012258 submit/tizen/20191031.023155 submit/tizen/20191031.111959 submit/tizen_5.5/20191115.014019
Seung-Woo Kim [Tue, 22 Oct 2019 08:46:13 +0000 (17:46 +0900)]
soc: samsung: cal-if: exynos9110: remove clocks for secure world

In exynos9110, some clocks are protected by trustzone secure world,
and accessing them causes system abort. Not to access the clocks from
kernel in normal world, remove the clocks protected by secure
world including ispp, vts, mfcmscl, g3dp, chubp.

Change-Id: I6ef4de7bbb77f50492cc34f90f7e012fa55395cf
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
4 years agosoc: samsung: cal-if: exynos9110: remove a clock for unassigned block 46/216246/2
Seung-Woo Kim [Tue, 22 Oct 2019 10:45:52 +0000 (19:45 +0900)]
soc: samsung: cal-if: exynos9110: remove a clock for unassigned block

From exynos9110 clock sfr, sfr of BLK_MODEM is set as just 0 and
that means it is not assigned. Accessing clock for the block
causes memory abort accessing wrong address. So remove the clock
for unassigned modem block.

Change-Id: Id880ed48ef8d01f4d8c348642fdcffc4004997fd
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
4 years agovideo: fbdev: exynos: dpu9110: fix null pointer deference for recovery_cnt 72/216172/1
Seung-Woo Kim [Tue, 22 Oct 2019 01:52:24 +0000 (10:52 +0900)]
video: fbdev: exynos: dpu9110: fix null pointer deference for recovery_cnt

There is no drvdata for specific instance of dpp when it is not
assigned from dt, and accessing it without null check causes null
pointer deference. Fix the null pointer defercens when accessing
recovery_cnt.

Change-Id: Ie57024101d461b1135f341bd1f76b55d0d77ec73
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
4 years agoarm64: tizen_tw3_defconfig: Enable NETFILTER_XT_MATCH_OWNER config 28/211228/1 accepted/tizen_5.5_unified_mobile_hotfix tizen_5.5_mobile_hotfix accepted/tizen/5.5/unified/20191031.032629 accepted/tizen/5.5/unified/mobile/hotfix/20201027.060924 accepted/tizen/unified/20190801.113445 submit/tizen/20190801.010047 submit/tizen_5.5/20191031.000010 submit/tizen_5.5/20191031.000011 submit/tizen_5.5/20191031.000013 submit/tizen_5.5_mobile_hotfix/20201026.1851010 submit/tizen_5.5_mobile_hotfix/20201027.114301 tizen_5.5.m2_release
Seung-Woo Kim [Wed, 31 Jul 2019 07:31:01 +0000 (16:31 +0900)]
arm64: tizen_tw3_defconfig: Enable NETFILTER_XT_MATCH_OWNER config

Enable the NETFILTER_XT_MATCH_OWNER config option to use xt_owner
supplementary groups.

Change-Id: I3c40c2d41dd29eede403f430887aab8f1ee4eaea
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
4 years agonetfilter: xt_owner: bail out with EINVAL in case of unsupported flags 03/209203/1 accepted/tizen/unified/20190705.110614 submit/tizen/20190705.061120
Pablo Neira Ayuso [Fri, 7 Jun 2019 14:37:30 +0000 (16:37 +0200)]
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: I178cb193c6593b40d004e3110e512fcd5627d125

4 years agonetfilter: xt_owner: Add supplementary groups option 02/209202/1
Lukasz Pawelczyk [Fri, 10 May 2019 11:46:22 +0000 (13:46 +0200)]
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 support supplementary groups on netfilter]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: If8a18f3c90378800fdee702c4eb0d7ec7c8c744e

5 years agoarm64: dts: exynos: Support offload playback 17/206217/4 accepted/tizen/unified/20190602.221819 submit/tizen/20190530.011954
Jaechul Lee [Wed, 15 May 2019 07:17:02 +0000 (16:17 +0900)]
arm64: dts: exynos: Support offload playback

Change-Id: I9a000740ef332018484f4a055baa700b27093821
Signed-off-by: Jaechul Lee <jcsing.lee@samsung.com>
5 years agoscript: release.sh: allow the local build on 32bit machine 07/199307/1
Jaehoon Chung [Fri, 8 Feb 2019 09:39:50 +0000 (18:39 +0900)]
script: release.sh: allow the local build on 32bit machine

Allow the local build on 32bit machine, not only 64bit machine.

Change-Id: I7b8d9769bb1426b41ebde7b4eb8a5a74b6c3d5d6
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
5 years agodrm/tgm: tdm_pp: fix not to call sync fence without fence/dma_buf 53/197353/1 accepted/tizen/unified/20190114.060130 submit/tizen/20190111.030902
Hoegeun Kwon [Fri, 11 Jan 2019 00:55:37 +0000 (09:55 +0900)]
drm/tgm: tdm_pp: fix not to call sync fence without fence/dma_buf

When without fence or dma_buf, tdm_pp tries to call sync fence and
it causes null deference or not necessary error message. Fix not
to call sync fence without fence or dma_buf.

Change-Id: Ic762185f1934c7dd0489a2dc8332d5bace29bae5
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: Hoegeun Kwon <hoegeun.kwon@samsung.com>
5 years agoarm64: tizen_tw3_defconfig: enable SECURITY_SMACK_APPEND_SIGNALS 30/197030/2 accepted/tizen/unified/20190110.060355 submit/tizen/20190109.063522
Seung-Woo Kim [Wed, 9 Jan 2019 03:51:56 +0000 (12:51 +0900)]
arm64: tizen_tw3_defconfig: enable SECURITY_SMACK_APPEND_SIGNALS

Enable SECURITY_SMACK_APPEND_SIGNALS to allow smack rules denying
signal delivery while allowing IPC in Tizen.

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