summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-08-25ARM64: tizen_tw3_defconfig: enable a config prefech_128 for dm-veritytizen_6.0.m2_releasesubmit/tizen_6.0_hotfix/20201103.115106submit/tizen_6.0_hotfix/20201102.192906submit/tizen_6.0/20201029.205505submit/tizen/20200825.081721accepted/tizen/unified/20200826.133047accepted/tizen/6.0/unified/hotfix/20201103.045018accepted/tizen/6.0/unified/20201030.102849tizen_6.0_hotfixtizen_6.0accepted/tizen_6.0_unified_hotfixaccepted/tizen_6.0_unifiedJaehoon Chung1-1/+1
Enable CONFIG_DM_VEIRTY_HASH_PREFETCH_MIN_SIZE_128. Change-Id: I2b8f8c8aa91f9e50429c7f5d76f9a2973973e6df Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
2020-08-25md: dm-verity-target: change prefetch size to 128 if config is enabledJaehoon Chung1-0/+4
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>
2020-07-16config: tw3: enable cpuset controller for cgroupsubmit/tizen/20200716.040454accepted/tizen/unified/20200716.144554Maciej Słodczyk1-1/+2
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>
2020-07-03lib: zstd: huf_decompress: Cleanup codeDongwoo Lee1-5/+1
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>
2020-06-15lib: zstd: Improve decode performanceDongwoo Lee6-377/+451
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>
2020-06-15block: zram: Add support for dynamic compressor switchDongwoo Lee4-58/+103
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>
2020-06-03zram: add zstd to the supported algorithms listSergey Senozhatsky1-0/+3
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
2020-06-03arm64: tizen_tw3_defconfig: Enable ZSTD cryptoDongwoo Lee1-0/+5
This enables zstd crypto for tw3 to support it as zram compressor. Change-Id: I5cf2bd6c0b016e53023764c2a297c741f23eda6e Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>
2020-06-03crypto: Add zstd supportNick Terrell5-0/+356
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
2020-06-03lib: Add zstd modulesNick Terrell19-0/+12998
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
2020-06-03lib: Add xxhash moduleNick Terrell4-0/+740
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
2020-06-03crypto: acomp - add driver-side scomp interfaceGiovanni Cabiddu7-29/+578
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
2020-06-03crypto: acomp - add asynchronous compression apiGiovanni Cabiddu8-0/+502
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
2020-05-18Bluetooth: Add error handling logic of LE data batchingsubmit/tizen/20200526.073613accepted/tizen/unified/20200528.132937Deokhyun Kim3-5/+50
Change-Id: Idb111d65552ef484cdf5a5f4d795d94a2c165db9 Signed-off-by: Deokhyun Kim <dukan.kim@samsung.com> Signed-off-by: Wootak Jung <wootak.jung@samsung.com>
2020-05-11arm64: dts: tw3: use array for motor strength and frequency setting for ↵jeongsup.jeong33-132/+66
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>
2020-05-11Motor: use default frequency when platform frequency request is predefined ↵jeongsup.jeong2-21/+22
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>
2020-05-11Motor: change motor control parameters for new haptic conceptjeongsup.jeong2-89/+122
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>
2020-05-11Motor: add handling freq, overdrive param on ff effectjeongsup.jeong2-63/+106
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>
2020-05-11Motor: ztm620: add motor status interfacejeongsup.jeong2-0/+9
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>
2020-05-11motor: ztm620: set dc motor dt and add switch motor typewoochul.shin2-7/+17
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>
2020-05-11Motor: ztm620: add pm_notifierjeongsup.jeong2-90/+185
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>
2020-05-08usb: gadget: f_fs: Limit data buffer size to a single pagesubmit/tizen/20200508.072818accepted/tizen/unified/20200510.220449Dongwoo Lee1-0/+7
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>
2020-05-08Revert "usb: gadget: f_fs: Give chance to retry malloc for large size buffer"Dongwoo Lee1-27/+3
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>
2020-04-01Bluetooth: Add GATT data batchingsubmit/tizen/20200331.090714accepted/tizen/unified/20200402.155630Wootak Jung5-0/+390
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>
2020-03-02Input: tizen_bezel: Change event value of the bezel devicesubmit/tizen/20200323.012640accepted/tizen/unified/20200324.101622lsmin.lee2-19/+22
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
2020-03-02Bluetooth: SMP: fix crash in unpairingsubmit/tizen/20200302.034238accepted/tizen/unified/20200302.125741Matias Karhumaa3-10/+29
[ 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
2020-03-02Bluetooth: Fix missing encryption refresh on Security RequestSzymon Janc1-1/+7
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
2020-01-02arm64: relocatable: fix inconsistencies in linker script and optionssubmit/tizen/20200102.014302accepted/tizen/unified/20200102.220848Ard Biesheuvel2-5/+6
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
2020-01-02arm64: remove no-op -p linker flagGreg Hackmann1-1/+1
(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
2020-01-02arm64: prevent regressions in compressed kernel image size when upgrading to ↵Nick Desaulniers1-2/+6
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
2019-12-31arm64: Don't unconditionally add -Wno-psabi to KBUILD_CFLAGSsubmit/tizen/20191231.055421accepted/tizen/unified/20200101.120530Nathan Chancellor1-1/+1
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
2019-12-31arm64: Silence gcc warnings about arch ABI driftDave Martin1-0/+1
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
2019-12-27Input: zxt_ztm620_ts: Remove possible overflow by using strlcat()Seung-Woo Kim1-117/+63
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>
2019-12-27Input: zxt_ztm620_ts: Repalce meaningless strncat() to strcat()Seung-Woo Kim1-26/+26
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>
2019-12-27soc: samsung: cal-if: fix not to calculate array size from nullSeung-Woo Kim4-299/+327
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>
2019-12-27video: fbdev: exynos: dpu9110: panel: s6e36w3x01: remove buffer overflowSeung-Woo Kim1-1/+1
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>
2019-12-27AsoC: speedy: fix sizeof-pointer-memaccess for strncpy()Seung-Woo Kim1-1/+1
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>
2019-12-27net: bcmdhd: Fix string concatenate with strncat()Seung-Woo Kim1-1/+1
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>
2019-12-27arm64: tizen_tw3_defconfig: Enable CONFIG_CRYPTO_CCMAnupam Roy1-3/+4
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>
2019-12-27arm64: tizen_tw3_defconfig: sync USB_CONFIGFS related config optionsSeung-Woo Kim1-0/+19
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>
2019-12-23cfg80211: Fix array-bounds warning in fragment copyMatthias Kaehlcke1-3/+3
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
2019-12-23ip_tunnel: Fix name string concatenate in __ip_tunnel_create()Sultan Alsawaf1-2/+2
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
2019-12-23tracing: Silence GCC 9 array bounds warningMiguel Ojeda3-10/+20
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
2019-12-23gcc-9: silence 'address-of-packed-member' warningLinus Torvalds1-0/+1
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
2019-12-23unifdef: use memcpy instead of strncpyLinus Torvalds1-2/+2
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
2019-12-23arm64, vdso: Define vdso_{start,end} as arrayKees Cook1-5/+5
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
2019-12-23Kbuild: suppress packed-not-aligned warning for default setting onlyXiongfeng Wang1-0/+3
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
2019-12-23disable stringop truncation warnings for nowStephen Rothwell1-0/+3
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
2019-12-23kconfig: Avoid format overflow warning from GCC 8.1Nathan Chancellor1-1/+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
2019-12-23exec: avoid gcc-8 warning for get_task_commArnd Bergmann2-5/+8
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
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-25 02:19:42 +0000