Commit Graph

5820 Commits

Author SHA1 Message Date
Andrey Zhizhikin
e6b0c6d89d This is the 5.4.40 stable release
-----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAl63u+YACgkQONu9yGCS
 aT5kKA/7BGDWIaU2l2UEdZNS2csysHu27XBH9KrwLaE6wFrysBgNMMYTnC6LkwxC
 GD4YUEBa67O0ehNfbrYMUkMbV/fZjyuveiCyrKTf2je3Vm07bWMxmQMiAp0UQHNh
 F+b0/IWqfZ7514PHInRhnesM3s0c9JSDf6Cq/JslwgZLm/Vfyny7kHJpQKoT2QGb
 rnxUwINUNQ1ei9tfN0x3/wix/Nk8xlHi1CmjsE9Qqpsi7tD/sBhg+LSUwo6K7yLb
 37c2IJHSkUhyy3lgL8GVbWVQannk0E1uVBlVxRERLYd5FOF2zJFojYv9lD8DJH8/
 iznCYbCcgXKNM23YTPlcNlaIrE8QBhLYezYu5BA8j5PU9l5AT1t4saJRNXChBJ9Y
 Lajd2Qo28Zvc1PZFA0ecOurd7WXfmcUyhCkHcCj6VuzA3UQZrYIiXZyWiQcJ68jB
 CtR8sRobxvmXhRQkbvFeN24rFfczFr6r3SNkXQ1VDJ9uey84kpDkZstguy5WUVKU
 ZVzeRAfFIPc4phG/nbiwkZGanOEI6Snsg/lLvhJ30v+/HSegnWojKMjqzgyYvBVp
 /UHpAImMs0WEFI/Ls6sMxOhJ3Kixwu8aHvJM2VV94eyNMF9wf5EOlZ4qWEe6ayR0
 09BaNwU7LWCcd0OaMoIo/LhaMKIl0WkcWJwI2/sC008BxsLSIhk=
 =16NP
 -----END PGP SIGNATURE-----

Merge tag 'v5.4.40' into 5.4-1.0.0-imx

This is the 5.4.40 stable release

No conflicts recorded during update

Signed-off-by: Andrey Zhizhikin <andrey.zhizhikin@leica-geosystems.com>
2020-05-12 21:06:54 +00:00
Tuowen Zhao
78b19f56b9 lib: devres: add a helper function for ioremap_uc
[ Upstream commit e537654b7039aacfe8ae629d49655c0e5692ad44 ]

Implement a resource managed strongly uncachable ioremap function.

Cc: <stable@vger.kernel.org> # v4.19+
Tested-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Tuowen Zhao <ztuowen@gmail.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Luis Chamberlain <mcgrof@kernel.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-05-10 10:31:30 +02:00
Nathan Chancellor
07fea3d3ef lib/mpi: Fix building for powerpc with clang
[ Upstream commit 5990cdee689c6885b27c6d969a3d58b09002b0bc ]

0day reports over and over on an powerpc randconfig with clang:

lib/mpi/generic_mpih-mul1.c:37:13: error: invalid use of a cast in a
inline asm context requiring an l-value: remove the cast or build with
-fheinous-gnu-extensions

Remove the superfluous casts, which have been done previously for x86
and arm32 in commit dea632cadd ("lib/mpi: fix build with clang") and
commit 7b7c1df288 ("lib/mpi/longlong.h: fix building with 32-bit
x86").

Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://github.com/ClangBuiltLinux/linux/issues/991
Link: https://lore.kernel.org/r/20200413195041.24064-1-natechancellor@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-05-10 10:31:28 +02:00
Andrey Zhizhikin
4051abfe4d This is the 5.4.36 stable release
-----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAl6pkDUACgkQONu9yGCS
 aT7cRxAAgnedn6pSj8x/LcbtqeQv52CDVXF0j1xOeK+o8hbIbvkjqAB1ZpPwAXaK
 PPiI34lzLBRo9i5nw/rOL7TR7q+uqLE/bT4Z8rrlbeq85SmP8PI2HwpPnRc3Iwhi
 RReIq00q5gBqF6AL7+Of3dEytrpOtyzf3Ff/3vadJ2WZEcblFoemGDjMbubaoI9E
 e2uE6WSe4tYk/pbLu5HduMQ46YGsWvTJAnN0RIefX4WsGmK0sCJRmJ78qIabWTct
 rUxoqhNHshPam7Qm6xVXe1pHa3U7zMNNtG52aJwoDzZ32rOTpBJly0F5FYYYW01Z
 zZbY/8eeGn4OIwGr+wvw/XmB0uYlBw35HH8f5OYpvSnfgjmT7wa8QmRJAS6um7dD
 elNqO1QuLa8lA/Tm5O9lzNIc3Vko322XQmGlsIU2xVBX0EdTig4Io+xuJkMMkU7q
 JJF4Ic4xOYa330TZBIKEoXgf4hGhNgKKRML00yhDNWROWXdB9W9tLbFELDiiiF+K
 ooeTB4aCsS2PheS/kZFL2U1RKlnMzBhYeZzPAg4ulfaVMHo5Zp8mBv4L17j9yU0+
 MtKtS9tSV0SiDe2SpDCRKSMx+m5jpmgXxuX4HlkbSJ4d/5oAwNKQOTQj9xt3UmbL
 JUghr8OOyk6V2wwgW1tFkTcFnzqCqzmvSeJf6AvBSr7ZHnqH130=
 =7Fsb
 -----END PGP SIGNATURE-----

Merge tag 'v5.4.36' into 5.4-1.0.0-imx

This is the 5.4.36 stable release

Signed-off-by: Andrey Zhizhikin <andrey.zhizhikin@leica-geosystems.com>
2020-04-30 17:53:45 +00:00
Masahiro Yamada
8652254e96 lib/raid6/test: fix build on distros whose /bin/sh is not bash
[ Upstream commit 06bd48b6cd97ef3889b68c8e09014d81dbc463f1 ]

You can build a user-space test program for the raid6 library code,
like this:

  $ cd lib/raid6/test
  $ make

The command in $(shell ...) function is evaluated by /bin/sh by default.
(or, you can specify the shell by passing SHELL=<shell> from command line)

Currently '>&/dev/null' is used to sink both stdout and stderr. Because
this code is bash-ism, it only works when /bin/sh is a symbolic link to
bash (this is the case on RHEL etc.)

This does not work on Ubuntu where /bin/sh is a symbolic link to dash.

I see lots of

  /bin/sh: 1: Syntax error: Bad fd number

and

  warning "your version of binutils lacks ... support"

Replace it with portable '>/dev/null 2>&1'.

Fixes: 4f8c55c5ad ("lib/raid6: build proper files on corresponding arch")
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Acked-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-04-29 16:33:00 +02:00
Gary Bisson
0ba14f4399 This is the 5.4.35 stable release
-----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAl6hU54ACgkQONu9yGCS
 aT5/3BAAlSOFEbVYeiAjDQYfA5DvieeVN3qKk0HnErIPRm35UHqCYSMyEDiJ2c8E
 01V2aFpvAZDyj/pE/prBrUH5FnKyil9tPQrg/da2f54yMiXQvQ6iFdmH/N5Zp5eu
 oY6qFUo4jePTbmI/TBzz08XZ9B4VxccNRhSdF0dO4SInt3eC+vJho3dCXH8H3B7o
 cDf4uIXQqyGn6t9yQQlSVRYTCK1JMwkSVxCU7uMWS5TfJSN3EyZvMMfXyTCTmgIy
 13Vv3+nSHxGqgyAA3fsClCGGAeQyFGQXP28OqyzesPuYyi5z3nDKtgZcAVtvyw9I
 eDsfnOUrw76StiJwRfnKkbg8TBKDWn4N9VyLyBvjRvRovSzTJ31jKVBLhByKDJQt
 cnsi/Ttkm2CYmChozdJrm1Pfm6HH5etEXh6rq4sqeGLkpi+k1UiQgYlavJPOI3nz
 n6dMQEyeg1dmAIBXqgvSvGVfyZuRi37ApPHMHEY4klALbRaSj2Vu/pblyeRezIXL
 G5D7olchwI0X18khdoBYOT1+tmid1pDZ00WB6Iq5IKIjR5x8KBf5uMcvprAc3LsP
 mhGP9+MYXhWQ/GjHjA6TZq76qhYlEZBIHBarIaNjrl3IShLTQXzxAwS8rGtI5wZP
 fTlCc+FBg5w1LDiVcEYJHXR583jSgsFTd3qbtpeaaQyKcC/fkEk=
 =3/4K
 -----END PGP SIGNATURE-----

Merge tag 'v5.4.35' into 5.4-1.0.0-imx

This is the 5.4.35 stable release
2020-04-27 13:55:49 +02:00
Slava Bacherikov
aea3873fb0 kbuild, btf: Fix dependencies for DEBUG_INFO_BTF
commit 7d32e69310d67e6b04af04f26193f79dfc2f05c7 upstream.

Currently turning on DEBUG_INFO_SPLIT when DEBUG_INFO_BTF is also
enabled will produce invalid btf file, since gen_btf function in
link-vmlinux.sh script doesn't handle *.dwo files.

Enabling DEBUG_INFO_REDUCED will also produce invalid btf file,
and using GCC_PLUGIN_RANDSTRUCT with BTF makes no sense.

Fixes: e83b9f5544 ("kbuild: add ability to generate BTF type info for vmlinux")
Reported-by: Jann Horn <jannh@google.com>
Reported-by: Liu Yiding <liuyd.fnst@cn.fujitsu.com>
Signed-off-by: Slava Bacherikov <slava@bacher09.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Kees Cook <keescook@chromium.org>
Acked-by: KP Singh <kpsingh@google.com>
Acked-by: Andrii Nakryiko <andriin@fb.com>
Link: https://lore.kernel.org/bpf/20200402204138.408021-1-slava@bacher09.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-23 10:36:18 +02:00
Gary Bisson
4b462e01ed This is the 5.4.33 stable release
-----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAl6ZbdIACgkQONu9yGCS
 aT5Jqw/7BZ639nTAAmz809yOF1JBhvBptRg9tBKYAfw62DzfZe5s9IZA6znIt0f0
 nlluLvnhHlDSpgycHNkFry5AkiCUpRQW6NY681xITm918w3BxsKX2pfCawojIOSw
 YBaTWoWqNFQQWlC18L1CWJmIvIktSCHXBMTVDpnvRv7sw5A4Oe/zarzVDNb0A6OJ
 ThaR7LAKJrUEDDLuCOuB/IrYCOpOzg2SkViFmlo4wmmhvCSi8PXvf3royrSFXxM/
 Y1bs67Hu/uqeHl8Y2RaMZpXf1aW9F31sooca4GD+UnVoWppjIOKRyuGLTrXKv7pw
 /goIzlE8wfJz5K0iQ4UcbXwwdY81L9UlMdVsmIWHHgxMjSp1J5mfQ5TLUC/VK3UO
 Ll9tCYBwH4FjzxNRJq7if8TDAfgPzyhw4BMchgXZWzW1oasl51T2uEye3KgFXQSb
 u6TwCx4KGS0w/Q81SKis83Pb0unHGanJOSCZxI1B44raf0ruCBpTYUc713pfegWT
 46YtwoorAK8N+GpFQA1tsTJvVclqCF5bHVE19TMvXV4UX/VTPtbIAUE7vnvcxcqO
 uh0b9Jfmd6Fcgh7VZQCH7CUYnsyJmGqj2kycB1p+T8UB6H+PCeuQBZBl8sJnf8oj
 d5NIzB7WWXBQuEG5XuPtxg6+ARMPEIpd2exEVn9ZOv5qhesBo04=
 =pjAq
 -----END PGP SIGNATURE-----

Merge tag 'v5.4.33' into 5.4-1.0.0-imx

This is the 5.4.33 stable release
2020-04-17 16:07:32 +02:00
Matthew Wilcox (Oracle)
07378b0991 xarray: Fix early termination of xas_for_each_marked
commit 7e934cf5ace1dceeb804f7493fa28bb697ed3c52 upstream.

xas_for_each_marked() is using entry == NULL as a termination condition
of the iteration. When xas_for_each_marked() is used protected only by
RCU, this can however race with xas_store(xas, NULL) in the following
way:

TASK1                                   TASK2
page_cache_delete()         	        find_get_pages_range_tag()
                                          xas_for_each_marked()
                                            xas_find_marked()
                                              off = xas_find_chunk()

  xas_store(&xas, NULL)
    xas_init_marks(&xas);
    ...
    rcu_assign_pointer(*slot, NULL);
                                              entry = xa_entry(off);

And thus xas_for_each_marked() terminates prematurely possibly leading
to missed entries in the iteration (translating to missing writeback of
some pages or a similar problem).

If we find a NULL entry that has been marked, skip it (unless we're trying
to allocate an entry).

Reported-by: Jan Kara <jack@suse.cz>
CC: stable@vger.kernel.org
Fixes: ef8e5717db ("page cache: Convert delete_batch to XArray")
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-17 10:50:18 +02:00
Matthew Wilcox (Oracle)
8f4c8e92bd XArray: Fix xas_pause for large multi-index entries
commit c36d451ad386b34f452fc3c8621ff14b9eaa31a6 upstream.

Inspired by the recent Coverity report, I looked for other places where
the offset wasn't being converted to an unsigned long before being
shifted, and I found one in xas_pause() when the entry being paused is
of order >32.

Fixes: b803b42823 ("xarray: Add XArray iterators")
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-17 10:50:18 +02:00
Gary Bisson
98da479f90 This is the 5.4.32 stable release
-----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAl6UJ1IACgkQONu9yGCS
 aT6i1A//RmLhD1Td+1pGWODgsMtfYD1FMB07D2uyFlX/NJe3jnhR9XGIKjFEtFSt
 bLXoQZlm07GPS7fsll7rE6Ydq0b1c5z59l+5pFCP4cc0ehM3Gca/V77ui0YBh9Mq
 /Jvk70qyE4en20qTia16cjozUjMreYPDdbqoR4rB3Lq+ALEEOwS0G4h2Nd4PTYGp
 YDXBwYn+O/f+CAl1arQeOSwpEThGGA4giSzBGaevq09xl2oIs4hAIWTpZ0WtugjR
 C4AXSEfl9Y/3OcYJm9KYVx4HqyunDhM3rY5ecCZXqeG4g9i5PZob9KisHuhs4nDD
 CBHd8ALTk0jo869MpizJ7nlcaGWPzBMSyxQeo1icq340KZjH/zWm7FY72VL+tBI0
 DSpPyP7zJmQESuZGRWfjLZkETH3edg6VI9233pB6OSfddYh7asrDVcw1jwMpr6Pf
 Y71aR7D9cYVyNPAP5AzQzdKUQlEPW1t4GhW6Cwxt7lbMZV18N73vYUxpl7IjSUa6
 6J5FHEIylnOFmpObzEC4Rj45Poy5ziI44/jmKMf7jmua9IAmHK2Dd6X5XjCRX40C
 Urf5it+wC5vkHVS6SW1tN4kbBhDfThHsAG71a3Y7kZeSpT6MrgneLEM9/BNk+csv
 gKTMukqZrgmR+zYTY78nbwM/XflqIqSwkF97GNvalyvT48Cokco=
 =Wb3/
 -----END PGP SIGNATURE-----

Merge tag 'v5.4.32' into 5.4-1.0.0-imx

This is the 5.4.32 stable release
2020-04-15 14:33:32 +02:00
Gary Bisson
2c127148e2 This is the 5.4.31 stable release
-----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAl6NeIEACgkQONu9yGCS
 aT6MYhAAl32aRPkceCidQx1xxOtwPHj/to5aKlqlJZL83wUHtyKI7QYZ6/xE4nAO
 hT668KM//KKg3UYeuAizfVUIQk703iDZvfQtffkZ1GP9WtyTWq0Iv4nZm7ohzUNH
 rTTyF+g1DJwewn+9qpkW2hqUviSsu6dGzIgmmO82M1Egu6Dcc03DxMIlUO+2fCLC
 j9R1vDeyzigmrO7o5lHngor3Re1TI5uLTonNZTdlhJIe7qc9z3aajoucGG4QcwuO
 99k08F64dwXK+JV2SJQ+E0NBQlwbYLer0HTCyO6xTGT90WfH6tDYDM7zi4UT42qi
 UwDhChmxr3ezffuNnNttIt+xt3PTuCjBJOgMSt1F1jb7IA0a1H2GOTUJUBn4S8ol
 ocTqpHymDJEgJ1fBjLHbN+ZZrsCeTgWyBu/FL71Pw5CtoY+Z/EsN64XBrbO4uMB8
 rB48d+TksikLLZ/qBja0bSXUUh2wVdBZ5EbjcPTetqmeOmvl5xGLxRks0HT62BuD
 BAT3nJ3rOMgc7INK2WJL3QlGqnJLXKu3wPtbq29ADfgLnbOt8WAPs4KooZKZpeh2
 fkiLUQ2UEFkEOiXjmh/JAHR8mUVa7NXbb0IILDpMW9vZINT69gFeXs43RRcZ1O+8
 G369xEweZg0T30sj1KLOLzgxP/K1EPXdq1FvvByUynsRuCFBVk8=
 =Bu2+
 -----END PGP SIGNATURE-----

Merge tag 'v5.4.31' into 5.4-1.0.0-imx

This is the 5.4.31 stable release
2020-04-15 14:32:49 +02:00
Gary Bisson
ab7a5abb75 This is the 5.4.24 stable release
-----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAl5hHjgACgkQONu9yGCS
 aT6CSBAA0c16mnDb59jgmW/sBj/p/MrlD/WJzLriqiKN5BUsPt9++I5mNj8mG+d2
 Glm4086e8L826zv8oKiZm23xk93on+78ExhVFVZvZNaEUpiRNYCGSuDq2NrHW0z+
 kpagkAFLfCUZFoKtmWo+bpl0YtF4dd/fg7+EjyL6qT1DBs8NVMwZx7i/v0xXv7Wc
 0vsGCLYoBLzcW1FB2d9cfAUPCBuGEzL/7TdifNOXRgI9owGsZndFJgXgIzoBUt/P
 tqB8RLjIupCiMEPtsEAZ/rgEQLPFkb3yrBvgjd1wDI8bHUIQU0clqThKVNvmNSmv
 UTBSNgPAhkP8nZG7X9xCkyfEsUefejBJy66da9n4XTGGrXf9ga0BL0nNrOGwOesr
 m+tNnBSFsbFCMqFopQnt4zZSnaf67AOk2mzxbEu4E+sStyW943aDO9MoRRFgaYGH
 pfie3qOKtKta2MuNTJA+q6F0W9H+V5MtMpwbyuy1/dp2eVln2wewBBMvXYdL1YOy
 E/Z87nsQgalsDynz9m/niv32J4JAxHptyOyROkktDLBSzL5RawNn+Op8X5EtmZOe
 sPkiYicqp9CLmMj13qWXJhtuyNdD4wk6FyyAy6cX9mF44+EZGOBkyNP+n8g789Kn
 sqFJ7sfTfOnwLBFciMA5PaMTGNWROyWXNkvvUzO+9t0CyFAnT2U=
 =abGA
 -----END PGP SIGNATURE-----

Merge tag 'v5.4.24' into 5.4-1.0.0-imx

This is the 5.4.24 stable release
2020-04-15 14:31:08 +02:00
Gary Bisson
2aaf60ea7f This is the 5.4.23 stable release
-----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAl5ZPksACgkQONu9yGCS
 aT4X0A//YvcKCCLgtWdQsWVJ0PEf5YE2KQI4rvbbD7wKkE5S6AWMhL3D+t46cWVe
 EgBtZLJYFkfqhdfF4JqjPsof/3CYS4o/LnAqzo0BgnnFccLV25SsGqDMn1b5Z6K2
 2vUs3gRydFk8iAWFs6XxrxScUbYrqr+6rQcLvgWHuMXjOInYPBUdc6b+vYMRsY79
 Eil6ROUy0daQPDJzfFrODW+OiUQ8uUx0F9Mq3fhuzNwx8E1QBv0qoH6fFkCYOzNa
 rmyjETil09hjLFMVThGjJoUPEzog6135T/s+eRo7vR13XdHPLo8lvrRJNGnuFBct
 CPVEZBNDVE20TRXGCaKDM/T8BMgqZ3V4Kx9BFwCyP34LdGebKvOsNvoNX7AxlyvQ
 lfOEpJU3rBuEUaM32J842NoMaSbIrOYBwtrA/0XEMQhIyA26FjJsE9foJFog68gQ
 2fekQSKpzWHcw1k3kUPH5iYHjD4oEz3mVM+C12klszMeoGYmnkGpmW0GzhtDJZiL
 94LxhUo3vNzBN5ut1am5FrYMaw5YF0Ptnk6n4CWvU9NnvHesFNE/BFzok7yv03M+
 Mm0XDyGKO4xWnCIbj2nTfbKDoY3FL7nJJ1GhwmHb36V2ZURIkkSob4In2/JM18Gw
 ltYJTEPsK3SeomLQDNCpoSdRcp3G615b7k8H9agz14Loh4Tydh0=
 =ScbK
 -----END PGP SIGNATURE-----

Merge tag 'v5.4.23' into 5.4-1.0.0-imx

This is the 5.4.23 stable release
2020-04-15 14:30:59 +02:00
Gary Bisson
ea133a8e14 This is the 5.4.22 stable release
-----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAl5TfSAACgkQONu9yGCS
 aT4I8w//SU+w9Tj8Crpt1BI7Lk2AiTGvyZtX0wGd53vzFKGy+Wi1Oba1ybB+xyYw
 UgMJJpoOgp9gTatRgjDl0vO/7U7vZckigPpog3pSW+xq2JW0kTWGS2z04hUjWKkG
 W4l3sAGwHRv7MTBbpjECDSHv+6x6ZqlWcVodpkHqLNmGxR0mYuiB6Zu8QuCu1bl0
 K0SAlt+yd0laUt2bU3wpEqBwGXHepz+IqsqcYp78sAeytT8ds9ZfPxKv98CvLlXs
 VLVr87UqZy3Hkl6IWKGrmdhWbTZE+3AyjKnxlA8PovA0ET5xO/IFPLHVhVX+or+5
 UFp/1qvacr+EIu8CKvftc2n1CflaRXIn/QNpwdemh94mi/2TqiXiqAUu1EiW56vg
 /PUH8G72Q26AiWSmD3WRr09ohTu4hfz6fIDKV60qmdVe4AUffLw0SnBEE0VFA3/S
 lVKZeXKkePeMlHcTyRDQ6+/y49yjfq2exdrjetypOwRa1emHxj/YsfdnEWYfwT53
 sikMLjP4XA7v5rsDr9LJTwQL/V/7euu1Hr3lSGpRv8vmePprvfmivTLcY5tgvOTC
 GZ51Em+CxJ+W4vCJKHuM7i0nUvf2Knn5lBidq4KsvLRUuZ31mSXSfSn4bW6Gl/Jm
 RZPDC71MqT/FMtfuQLlVNqIw2umC1buNa5SwZ8GhJG6za4gU4FU=
 =L+e0
 -----END PGP SIGNATURE-----

Merge tag 'v5.4.22' into 5.4-1.0.0-imx

This is the 5.4.22 stable release
2020-04-15 14:30:19 +02:00
Gary Bisson
6504b00333 This is the 5.4.19 stable release
-----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAl5Cn6wACgkQONu9yGCS
 aT789BAAkpzYCCHEL2aqDpnZQdu1kVua2nywEJCY0WqSM1lWLeU1Lk9EvS6uu99B
 nHnIgoAGXR1zQy9rlhpKKt62LvCCM94QWlQRDYYeJxbFPn1ogT2/0vmwN7rqNz4M
 Jdszd6gfNKtB3zpZZLJ0KXG8q6YRp5kXOHEzOXNjcVsfKRuNTWWIBV0dMmkCzduQ
 Y5e62+d1FnnRFj28R7wjJfXiZSRnIGcMHohcQGXsWZsh2rktYOYsL6G37I9lCBwx
 RO7/+qVOT+BImqB5fIxB98JOzOlo6uEVqPgXjMHAAZUzzA4KpOkDBn55m5hA9axf
 EG67Ft4vZJc6Q3FTtHdSZZ/x6TBAJ2DUzatpKhCTDB3vlWJ6a+CsTFq3dXj4+bFr
 hFuyi0u91VeudmWR8IH5Er8QaNaOq8m72XAwK22fZptZz0ZHl+Bf1QZyEY0L0P2Q
 DpT/kmZVgSSDusvMtJOwI8Vr4Ibb8o46kFTQN+PCSs0pbPchEJmInHz0mIypK89N
 4YIjcDZZu3WUS13pEsgNAi2FEpwZdn32LYxZg8xTYBtovzuvT1pJUEppiVSMXgKS
 8vF6oCAd7pX9Fal5fYklA7gyQENnHBFI+LE+bHwMR/qwreH/3wBTLnhRPsGOxyZI
 oj57YDdxZCAwEfXGoWA3Le+60lj6bGuRfmCc4VkodaOxMLb1WrE=
 =rUtE
 -----END PGP SIGNATURE-----

Merge tag 'v5.4.19' into 5.4-1.0.0-imx

This is the 5.4.19 stable release
2020-04-15 14:30:05 +02:00
Gary Bisson
a48a1e55f9 This is the 5.4.18 stable release
-----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAl47Mi4ACgkQONu9yGCS
 aT4zURAAiRhPVfht+amxkX2ebcimGIDO7oMICICF4vAOn9zAHHzEuxjtQms0LWRN
 l91qduujbVHg9/81BzCe0qp5GwYsgJRAIB5sJwuCrtM5u8zSSQXIY58sU1ZUXLha
 UC7Pnez+f420RO/U4Xh3BnEM6GOj97VrLw3gePdmI+e4imwP+czloYR/sVLhHES3
 vHr7OFhYx8GF303RomFo4kuG9dz11ZUuPdrcHWxDRBHIf3bNCITGpjOV9ICZPL9+
 UqmrFZKyqXcT29pgwtUMIxobnkgQm9KekS8iYGS7pblu5BXTuvU6TvfKwpOMOdF3
 FIDV9km6LRFyydCLowuiA5gVuNQwfcXCIfPZfhX0ua0vC8e7q/DKItf7QBaChYyp
 tD4mjXGkOvIrZad94kSw3qVWr1bv9I4D5w+BmDoi5/zchjAcphUeij+QXEhmkD9k
 PB+zu3NbeY0J69QaVgCbPPHAmimIwsCKlA9FAJNMeuDwBIk7LXF7J0Y0ehlxwdTy
 h9/miG0UXYkeo5BhhdvvlZ9jdCVHI/fux+McObsasBL2xArmAA059GRgDag2qEo9
 X+rtszl8x1JIcPZ3lfm5aSsZ/8nQhtpfsl+mZKSM/x+Kl+SoryvgYtDJHg9Rf5Cp
 WPx5mD82fS9g1RaQmIWa7iZj4iNvLDf4I+ppe2JbEGUq5IYzZGY=
 =cfYj
 -----END PGP SIGNATURE-----

Merge tag 'v5.4.18' into 5.4-1.0.0-imx

This is the 5.4.18 stable release
2020-04-15 14:28:36 +02:00
Gary Bisson
237f322142 This is the 5.4.16 stable release
-----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAl4xqJ4ACgkQONu9yGCS
 aT5BdxAAwpqN58x/Y9hfA57/jOyjmB/slYHOnZ+JsGMF3HTaPAjztu/8KpTixbd2
 +ypoysWhXlBCeSdhndEQBbzXflabi748lxRBVzAnYjjYsQsCRuPgEVgcw7CAyEdW
 3/pbYN5XvQvN7SjDICMdkaCOj5zOJ/mIvZi+koLrq+mBVMs+qSOPxulobDD8tUl5
 JbetuWegVwe6wuADI0fsGOzIbiPMK0UoqgRzV5Y7KMbBNL5OGAdzCAFL0IudyTaD
 EH6ED/jcLqgULravhYQ3U4k+HxeADDL0/wf8Ki0XzVENXYTRwh/R1KMDbIH6nQm1
 scgIAB0d8Gt18eKDavd+cckCVBKV9sJZtfGywL61Q234SvT8aK19aKJS643M21Ey
 td1c7wvOXWrCdtNJT15uFTa0fRz7YZnT49dwFzdeKXMrYS+BnJQen3IzC+7nSp8Q
 4176BkbmpQdJ7a4twkBgJYPuNCpKyVMLFB+OIVO+dnzlqMMApH8StYhx51m21B7r
 8r/7e2TsCWqfmsiZ1I+WuFPoTvXGn7nm03H7mvfuo6d7MfvvJLXLTiIfMv+VjL1Q
 sh/NCaVAXz9aaLE5WYHa8FzUHnK6v/twZBA2AffpgkwNBRbfIQxHKBl3QMDpwpft
 92yAh3bHQXNfc17jpuFCIEgjD5haG7d5kwD6BvlBCfSjbIBE1B0=
 =ApNn
 -----END PGP SIGNATURE-----

Merge tag 'v5.4.16' into 5.4-1.0.0-imx

This is the 5.4.16 stable release
2020-04-15 14:28:27 +02:00
Gary Bisson
382fd61445 This is the 5.4.11 stable release
-----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAl4bAaMACgkQONu9yGCS
 aT6WThAApG5Lt+rOIIbb0JsTgiqzRs/5VkxQLDsDkn8QXMDDX44eY+cW3XLA+3nv
 UAU7wXraFCq7SznsQADHj4edAQN/urNXcIlLCIfoWCuq4Yk6DIgHNDZcC5a1PPiz
 ri96mrxHq24XDbRcXZFN4usC6Q1Q40W/N2NyZ7gIfCsYOeiaZzNhvw1Sh6Pkajb+
 jKe9Yzjolj2XJxrNgJxfsTJLnCEPwoQ/QoBIp1ffHqhhCjR/7tHm611Pj0q260Fj
 H6OGZaRNMoc4I+2dQXsYUfyPH5aMwx2/Nym4FNHye9LaoQl07m+uR0LqmytPQ0GL
 j6mQuMv+kdeVOOXO+zRJH8A2yq4mwvr80s15myhG9HvAzmcGAvagsCl19yy9/fJx
 6M2Sn8qDwJXRaxTc1e7figXkTZu5+sX7th3sUk0KbCHZ+UkJiCjXpJDgBK/HQkC3
 EsVFZGeIBySbWk2yYKzQkb4ZA32qbzUKW88Rjago3BOV96WHfnAhJDQPssDJqlcs
 cgK+UTQOJb9U1V+Kd4Z8uhlCeboaRj4yOFt2EGxkK2sqJse05eaTN0GPbP/3X6Be
 TyD17Cnv18Ltk2qf2DXanJSlrCUcHEfEDoQQTqJATxV4NLzTcwmVAscsv1aRmcot
 ii1ZTwqi04MLgaNla+6tqqZ/VufUtWVIbN73q2UdU8zZh5PHJ18=
 =cKx6
 -----END PGP SIGNATURE-----

Merge tag 'v5.4.11' into 5.4-1.0.0-imx

This is the 5.4.11 stable release
2020-04-15 14:24:28 +02:00
Gary Bisson
5252bc6c47 This is the 5.4.9 stable release
-----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAl4W8EgACgkQONu9yGCS
 aT4szA//fqXI1OQ3xcCt5s9MYZYYa6IpX/VZ0H7lNC/7pkJzccKo+aSer7ppEn4o
 ND8sHNx/lhfZorhvLdqJK4PLThC+fXmXnLvFOzqvZeUVyesnv9zlhd/5JNu18Fvc
 RNjcIRIAHFwanZLAw8uft1DIZXcZ8wNkAAugn/WQV3FN/TG+FsrDzWYnmbBhRIQS
 XC/2jSlFpMTKoExNzEdbduG0XH5plWeE+AdY3a+DQsOBUO2XrAuk5HTEByM1jzPV
 W7U9vMqvw3OyrERcA0lmjs37Waw1e0qzfUaa8Bman5Uc0StOTq0UwschX21SB5yP
 MvbAKhqaKtSff7b4lNrDP9Kj1O/lH84WPSn/aao9D083m/ZYdkkd4AWMlS480lL5
 oJ28tFbgwLayIqDbwCggHluTsNUdQSTwahVbnp4GMqxfjWrApdLPCqloSb+x9JCF
 9pWJf3awI53mA864pH/uOM7pDOz5/c/oJ4QzVmOmR48dsddorY+gPcwk+YpElJcZ
 +xCBQDN5JkNC7lwqu2lvaoq/5cMC5lO/v6aeTfsYCRVnlNY12TY8z352zzMZfCKG
 GRkNvDqWZ5ZmQ+LblWRVbgdGxU42wIYXUS1jUdFd+5DRzz17+ZKUy7YbLNmZMcpY
 UyiM2Ij7X7HsNGrYDKFq0lZPw6k7v3FshvMwQ8C6dNk+l3o9oCA=
 =M+hs
 -----END PGP SIGNATURE-----

Merge tag 'v5.4.9' into 5.4-1.0.0-imx

This is the 5.4.9 stable release
2020-04-15 14:23:47 +02:00
Gary Bisson
5eca9195d2 This is the 5.4.7 stable release
-----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAl4LbVwACgkQONu9yGCS
 aT6zdhAAkTwLWNfzyk1cSPKzWdguZWoqAuddmIeCUaDmyPwI6TE5a2J8IfZ7upYU
 4U2J4nO4I9WxVuTUgJpE0wnDidkvL6U7YfbMbqjVkxAfbFboxN8dJYDNTISehK2A
 WgpIpJadhj1M8Akxq0MLxuCMg11UJU2PP5Tc7K5aKgiVVneDodupjY8Ddksuw8SZ
 5Mus33uOjpCvtxt3GZIRgAdduhL3s3h2Vp+dyAzV2eBvSGwd9Rz4/p0OGZytH780
 oywFYzIU7CxtI7pxIQKBxegb4incjWnlRpP3Dk80CNXHzcuU6WGXARoHjgXmWYcu
 b9hX+/fM76qxbxojM1vI9QVuwy5uB++4NMVsX3e0xFxdvkTo2+Y/vbO3sBMmAy5i
 L0S0sftTuE6bg1XCWoeFbLUaXIWF7g0Xbc91VP7Wv5VolpIrwZsVHJNT4Nf8KHM4
 DuRLmrANhU7ax2E26Bbt17/otCFvjyeQj5fggw/1rkEN8fJSY1YU/SWOxizDY6GZ
 S3ovivhqhLIaDPzW+qmphYRGnBDkTq7HxHal8eJoy/cgvFxBOYAbfXiHuPuNP4Kj
 zbIThujSlbI0gNGymoHH8EoVOJeNcK8L2PsilIZdlPDWi45v5tqYIgiYIA7mqqu+
 6O2plNGWbYK2+ARPkCJ08XTdDFSm+B6Cm0+KFvsdjuQ6xNkhMwc=
 =HvEl
 -----END PGP SIGNATURE-----

Merge tag 'v5.4.7' into 5.4-1.0.0-imx

This is the 5.4.7 stable release
2020-04-15 14:15:21 +02:00
Gary Bisson
08d35172b2 This is the 5.4.4 stable release
-----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAl35Ju4ACgkQONu9yGCS
 aT7IMQ//Vs+kE7VCDeHfzNu4ivh3+X0bleYWo/OPxNQRFx7IL4Lb2jVjWrMnAGld
 u8H31nVaL28bhJAcQJg+O/OD3AXWQ8nzRKixfVfwd669Zv1ggaLM8MW9xuTBwmQs
 ciFrQ4GirfjvUP0VdkpsSLp+bbi61nkqGB4WHgX3gL+8LWxtpE8nFlh+8P+3TT9Z
 h4BuYQHhGF8JyhOFKhfWbWAFUoHLsR7Aa7TPOeQPXGfzWBaSfISA/UVo6N7QGpVw
 4DP5rc4Wb+tzNAJHkkgzbSDzuM6L6BHrO3SQCisd0Viw9XYO9M0U9NVbExtu9x9l
 M/sqE61cX1AxUmjstdgca37vyHCntJ+wMT7WRnOBVJfodZDjB/6wzPz8rWIZrSX+
 +uXSJF8Xpp5FuvB0td0CQoyUsnrMDnwWbjnMnlVXY6mPcgD5fgB9dTDJN3FEQ8t6
 MixN3JBy1KseY9ihe9cINaR0CBKqyogOwbGrqqw3XJNWzpJ5xgxhLuSc2PyuDLwZ
 bDaj7K9Ukx4n0QzXWvW5pZTQi+yNVc7DUVOKFDXTf2xR2/KvEVNW25gL7oBxrTTu
 q5gw4bBkO0KsbgofTMWUyUfO3aYhDqc7H4yfRRbc/Q08hiJHORFC2jhLXG9oubNN
 QrZ4AxJvzRSYl5vwrVpHW9vnlPe5SuJvRbkMN8164togc9BMNbc=
 =qUmE
 -----END PGP SIGNATURE-----

Merge tag 'v5.4.4' into 5.4-1.0.0-imx

This is the 5.4.4 stable release
2020-04-13 16:06:32 +02:00
Yury Norov
8b0f080366 uapi: rename ext2_swab() to swab() and share globally in swab.h
commit d5767057c9a76a29f073dad66b7fa12a90e8c748 upstream.

ext2_swab() is defined locally in lib/find_bit.c However it is not
specific to ext2, neither to bitmaps.

There are many potential users of it, so rename it to just swab() and
move to include/uapi/linux/swab.h

ABI guarantees that size of unsigned long corresponds to BITS_PER_LONG,
therefore drop unneeded cast.

Link: http://lkml.kernel.org/r/20200103202846.21616-1-yury.norov@gmail.com
Signed-off-by: Yury Norov <yury.norov@gmail.com>
Cc: Allison Randal <allison@lohutok.net>
Cc: Joe Perches <joe@perches.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: William Breathitt Gray <vilhelm.gray@gmail.com>
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>
2020-04-13 10:48:07 +02:00
Matthew Wilcox (Oracle)
16696ee7b5 XArray: Fix xa_find_next for large multi-index entries
[ Upstream commit bd40b17ca49d7d110adf456e647701ce74de2241 ]

Coverity pointed out that xas_sibling() was shifting xa_offset without
promoting it to an unsigned long first, so the shift could cause an
overflow and we'd get the wrong answer.  The fix is obvious, and the
new test-case provokes UBSAN to report an error:
runtime error: shift exponent 60 is too large for 32-bit type 'int'

Fixes: 19c30f4dd092 ("XArray: Fix xa_find_after with multi-index entries")
Reported-by: Bjorn Helgaas <bhelgaas@google.com>
Reported-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-04-08 09:08:40 +02:00
Masahiro Yamada
ecd77a3261 kbuild: move headers_check rule to usr/include/Makefile
commit 7ecaf069da52e472d393f03e79d721aabd724166 upstream.

Currently, some sanity checks for uapi headers are done by
scripts/headers_check.pl, which is wired up to the 'headers_check'
target in the top Makefile.

It is true compiling headers has better test coverage, but there
are still several headers excluded from the compile test. I like
to keep headers_check.pl for a while, but we can delete a lot of
code by moving the build rule to usr/include/Makefile.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-05 16:43:47 +01:00
Alexander Potapenko
9bb971b335 lib/stackdepot.c: fix global out-of-bounds in stack_slabs
commit 305e519ce48e935702c32241f07d393c3c8fed3e upstream.

Walter Wu has reported a potential case in which init_stack_slab() is
called after stack_slabs[STACK_ALLOC_MAX_SLABS - 1] has already been
initialized.  In that case init_stack_slab() will overwrite
stack_slabs[STACK_ALLOC_MAX_SLABS], which may result in a memory
corruption.

Link: http://lkml.kernel.org/r/20200218102950.260263-1-glider@google.com
Fixes: cd11016e5f ("mm, kasan: stackdepot implementation. Enable stackdepot for SLAB")
Signed-off-by: Alexander Potapenko <glider@google.com>
Reported-by: Walter Wu <walter-zh.wu@mediatek.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Kate Stewart <kstewart@linuxfoundation.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: <stable@vger.kernel.org>
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>
2020-02-28 17:22:20 +01:00
Nathan Chancellor
23b88b51de lib/scatterlist.c: adjust indentation in __sg_alloc_table
[ Upstream commit 4e456fee215677584cafa7f67298a76917e89c64 ]

Clang warns:

  ../lib/scatterlist.c:314:5: warning: misleading indentation; statement
  is not part of the previous 'if' [-Wmisleading-indentation]
                          return -ENOMEM;
                          ^
  ../lib/scatterlist.c:311:4: note: previous statement is here
                          if (prv)
                          ^
  1 warning generated.

This warning occurs because there is a space before the tab on this
line.  Remove it so that the indentation is consistent with the Linux
kernel coding style and clang no longer warns.

Link: http://lkml.kernel.org/r/20191218033606.11942-1-natechancellor@gmail.com
Link: https://github.com/ClangBuiltLinux/linux/issues/830
Fixes: edce6820a9 ("scatterlist: prevent invalid free when alloc fails")
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-02-24 08:37:00 +01:00
Marco Elver
84255fe86d debugobjects: Fix various data races
[ Upstream commit 35fd7a637c42bb54ba4608f4d40ae6e55fc88781 ]

The counters obj_pool_free, and obj_nr_tofree, and the flag obj_freeing are
read locklessly outside the pool_lock critical sections. If read with plain
accesses, this would result in data races.

This is addressed as follows:

 * reads outside critical sections become READ_ONCE()s (pairing with
   WRITE_ONCE()s added);

 * writes become WRITE_ONCE()s (pairing with READ_ONCE()s added); since
   writes happen inside critical sections, only the write and not the read
   of RMWs needs to be atomic, thus WRITE_ONCE(var, var +/- X) is
   sufficient.

The data races were reported by KCSAN:

  BUG: KCSAN: data-race in __free_object / fill_pool

  write to 0xffffffff8beb04f8 of 4 bytes by interrupt on cpu 1:
   __free_object+0x1ee/0x8e0 lib/debugobjects.c:404
   __debug_check_no_obj_freed+0x199/0x330 lib/debugobjects.c:969
   debug_check_no_obj_freed+0x3c/0x44 lib/debugobjects.c:994
   slab_free_hook mm/slub.c:1422 [inline]

  read to 0xffffffff8beb04f8 of 4 bytes by task 1 on cpu 2:
   fill_pool+0x3d/0x520 lib/debugobjects.c:135
   __debug_object_init+0x3c/0x810 lib/debugobjects.c:536
   debug_object_init lib/debugobjects.c:591 [inline]
   debug_object_activate+0x228/0x320 lib/debugobjects.c:677
   debug_rcu_head_queue kernel/rcu/rcu.h:176 [inline]

  BUG: KCSAN: data-race in __debug_object_init / fill_pool

  read to 0xffffffff8beb04f8 of 4 bytes by task 10 on cpu 6:
   fill_pool+0x3d/0x520 lib/debugobjects.c:135
   __debug_object_init+0x3c/0x810 lib/debugobjects.c:536
   debug_object_init_on_stack+0x39/0x50 lib/debugobjects.c:606
   init_timer_on_stack_key kernel/time/timer.c:742 [inline]

  write to 0xffffffff8beb04f8 of 4 bytes by task 1 on cpu 3:
   alloc_object lib/debugobjects.c:258 [inline]
   __debug_object_init+0x717/0x810 lib/debugobjects.c:544
   debug_object_init lib/debugobjects.c:591 [inline]
   debug_object_activate+0x228/0x320 lib/debugobjects.c:677
   debug_rcu_head_queue kernel/rcu/rcu.h:176 [inline]

  BUG: KCSAN: data-race in free_obj_work / free_object

  read to 0xffffffff9140c190 of 4 bytes by task 10 on cpu 6:
   free_object+0x4b/0xd0 lib/debugobjects.c:426
   debug_object_free+0x190/0x210 lib/debugobjects.c:824
   destroy_timer_on_stack kernel/time/timer.c:749 [inline]

  write to 0xffffffff9140c190 of 4 bytes by task 93 on cpu 1:
   free_obj_work+0x24f/0x480 lib/debugobjects.c:313
   process_one_work+0x454/0x8d0 kernel/workqueue.c:2264
   worker_thread+0x9a/0x780 kernel/workqueue.c:2410

Reported-by: Qian Cai <cai@lca.pw>
Signed-off-by: Marco Elver <elver@google.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/20200116185529.11026-1-elver@google.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-02-24 08:36:52 +01:00
Zhengyuan Liu
a922fa72a8 raid6/test: fix a compilation warning
[ Upstream commit 5e5ac01c2b8802921fee680518a986011cb59820 ]

The compilation warning is redefination showed as following:

        In file included from tables.c:2:
        ../../../include/linux/export.h:180: warning: "EXPORT_SYMBOL" redefined
         #define EXPORT_SYMBOL(sym)  __EXPORT_SYMBOL(sym, "")

        In file included from tables.c:1:
        ../../../include/linux/raid/pq.h:61: note: this is the location of the previous definition
         #define EXPORT_SYMBOL(sym)

Fixes: 69a94abb82 ("export.h, genksyms: do not make genksyms calculate CRC of trimmed symbols")
Signed-off-by: Zhengyuan Liu <liuzhengyuan@kylinos.cn>
Signed-off-by: Song Liu <songliubraving@fb.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-02-24 08:36:47 +01:00
Gustavo A. R. Silva
db165906ca lib/test_kasan.c: fix memory leak in kmalloc_oob_krealloc_more()
commit 3e21d9a501bf99aee2e5835d7f34d8c823f115b5 upstream.

In case memory resources for _ptr2_ were allocated, release them before
return.

Notice that in case _ptr1_ happens to be NULL, krealloc() behaves
exactly like kmalloc().

Addresses-Coverity-ID: 1490594 ("Resource leak")
Link: http://lkml.kernel.org/r/20200123160115.GA4202@embeddedor
Fixes: 3f15801cdc ("lib: add kasan test module")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
Cc: <stable@vger.kernel.org>
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>
2020-02-11 04:35:14 -08:00
Matthew Wilcox (Oracle)
08022255a9 XArray: Fix xas_pause at ULONG_MAX
[ Upstream commit 82a22311b7a68a78709699dc8c098953b70e4fd2 ]

If we were unlucky enough to call xas_pause() when the index was at
ULONG_MAX (or a multi-slot entry which ends at ULONG_MAX), we would
wrap the index back around to 0 and restart the iteration from the
beginning.  Use the XAS_BOUNDS state to indicate that we should just
stop the iteration.

Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-02-05 21:22:47 +00:00
Christophe Leroy
9f6216862a lib: Reduce user_access_begin() boundaries in strncpy_from_user() and strnlen_user()
commit ab10ae1c3bef56c29bac61e1201c752221b87b41 upstream.

The range passed to user_access_begin() by strncpy_from_user() and
strnlen_user() starts at 'src' and goes up to the limit of userspace
although reads will be limited by the 'count' param.

On 32 bits powerpc (book3s/32) access has to be granted for each
256Mbytes segment and the cost increases with the number of segments to
unlock.

Limit the range with 'count' param.

Fixes: 594cc251fd ("make 'user_access_begin()' do 'access_ok()'")
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-29 16:45:29 +01:00
Matthew Wilcox (Oracle)
dd05cf12c7 XArray: Fix xas_find returning too many entries
commit c44aa5e8ab58b5f4cf473970ec784c3333496a2e upstream.

If you call xas_find() with the initial index > max, it should have
returned NULL but was returning the entry at index.

Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-29 16:45:27 +01:00
Matthew Wilcox (Oracle)
db38561288 XArray: Fix xa_find_after with multi-index entries
commit 19c30f4dd0923ef191f35c652ee4058e91e89056 upstream.

If the entry is of an order which is a multiple of XA_CHUNK_SIZE,
the current detection of sibling entries does not work.  Factor out
an xas_sibling() function to make xa_find_after() a little more
understandable, and write a new implementation that doesn't suffer from
the same bug.

Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-29 16:45:26 +01:00
Matthew Wilcox (Oracle)
a5135ca1f9 XArray: Fix infinite loop with entry at ULONG_MAX
commit 430f24f94c8a174d411a550d7b5529301922e67a upstream.

If there is an entry at ULONG_MAX, xa_for_each() will overflow the
'index + 1' in xa_find_after() and wrap around to 0.  Catch this case
and terminate the loop by returning NULL.

Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-29 16:45:26 +01:00
David Jeffery
dba0d9caa6 sbitmap: only queue kyber's wait callback if not already active
[ Upstream commit df034c93f15ee71df231ff9fe311d27ff08a2a52 ]

Under heavy loads where the kyber I/O scheduler hits the token limits for
its scheduling domains, kyber can become stuck.  When active requests
complete, kyber may not be woken up leaving the I/O requests in kyber
stuck.

This stuck state is due to a race condition with kyber and the sbitmap
functions it uses to run a callback when enough requests have completed.
The running of a sbt_wait callback can race with the attempt to insert the
sbt_wait.  Since sbitmap_del_wait_queue removes the sbt_wait from the list
first then sets the sbq field to NULL, kyber can see the item as not on a
list but the call to sbitmap_add_wait_queue will see sbq as non-NULL. This
results in the sbt_wait being inserted onto the wait list but ws_active
doesn't get incremented.  So the sbitmap queue does not know there is a
waiter on a wait list.

Since sbitmap doesn't think there is a waiter, kyber may never be
informed that there are domain tokens available and the I/O never advances.
With the sbt_wait on a wait list, kyber believes it has an active waiter
so cannot insert a new waiter when reaching the domain's full state.

This race can be fixed by only adding the sbt_wait to the queue if the
sbq field is NULL.  If sbq is not NULL, there is already an action active
which will trigger the re-running of kyber.  Let it run and add the
sbt_wait to the wait list if still needing to wait.

Reviewed-by: Omar Sandoval <osandov@fb.com>
Signed-off-by: David Jeffery <djeffery@redhat.com>
Reported-by: John Pittman <jpittman@redhat.com>
Tested-by: John Pittman <jpittman@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-01-12 12:21:44 +01:00
Julien Grall
735e7a12a6 lib/ubsan: don't serialize UBSAN report
[ Upstream commit ce5c31db3645b649a31044a4d8b6057f6c723702 ]

At the moment, UBSAN report will be serialized using a spin_lock().  On
RT-systems, spinlocks are turned to rt_spin_lock and may sleep.  This
will result to the following splat if the undefined behavior is in a
context that can sleep:

  BUG: sleeping function called from invalid context at /src/linux/kernel/locking/rtmutex.c:968
  in_atomic(): 1, irqs_disabled(): 128, pid: 3447, name: make
  1 lock held by make/3447:
   #0: 000000009a966332 (&mm->mmap_sem){++++}, at: do_page_fault+0x140/0x4f8
  irq event stamp: 6284
  hardirqs last  enabled at (6283): [<ffff000011326520>] _raw_spin_unlock_irqrestore+0x90/0xa0
  hardirqs last disabled at (6284): [<ffff0000113262b0>] _raw_spin_lock_irqsave+0x30/0x78
  softirqs last  enabled at (2430): [<ffff000010088ef8>] fpsimd_restore_current_state+0x60/0xe8
  softirqs last disabled at (2427): [<ffff000010088ec0>] fpsimd_restore_current_state+0x28/0xe8
  Preemption disabled at:
  [<ffff000011324a4c>] rt_mutex_futex_unlock+0x4c/0xb0
  CPU: 3 PID: 3447 Comm: make Tainted: G        W         5.2.14-rt7-01890-ge6e057589653 #911
  Call trace:
    dump_backtrace+0x0/0x148
    show_stack+0x14/0x20
    dump_stack+0xbc/0x104
    ___might_sleep+0x154/0x210
    rt_spin_lock+0x68/0xa0
    ubsan_prologue+0x30/0x68
    handle_overflow+0x64/0xe0
    __ubsan_handle_add_overflow+0x10/0x18
    __lock_acquire+0x1c28/0x2a28
    lock_acquire+0xf0/0x370
    _raw_spin_lock_irqsave+0x58/0x78
    rt_mutex_futex_unlock+0x4c/0xb0
    rt_spin_unlock+0x28/0x70
    get_page_from_freelist+0x428/0x2b60
    __alloc_pages_nodemask+0x174/0x1708
    alloc_pages_vma+0x1ac/0x238
    __handle_mm_fault+0x4ac/0x10b0
    handle_mm_fault+0x1d8/0x3b0
    do_page_fault+0x1c8/0x4f8
    do_translation_fault+0xb8/0xe0
    do_mem_abort+0x3c/0x98
    el0_da+0x20/0x24

The spin_lock() will protect against multiple CPUs to output a report
together, I guess to prevent them from being interleaved.  However, they
can still interleave with other messages (and even splat from
__might_sleep).

So the lock usefulness seems pretty limited.  Rather than trying to
accomodate RT-system by switching to a raw_spin_lock(), the lock is now
completely dropped.

Link: http://lkml.kernel.org/r/20190920100835.14999-1-julien.grall@arm.com
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reported-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-01-09 10:20:07 +01:00
Peter Zijlstra
39303579eb ubsan, x86: Annotate and allow __ubsan_handle_shift_out_of_bounds() in uaccess regions
[ Upstream commit 9a50dcaf0416a43e1fe411dc61a99c8333c90119 ]

The new check_zeroed_user() function uses variable shifts inside of a
user_access_begin()/user_access_end() section and that results in GCC
emitting __ubsan_handle_shift_out_of_bounds() calls, even though
through value range analysis it would be able to see that the UB in
question is impossible.

Annotate and whitelist this UBSAN function; continued use of
user_access_begin()/user_access_end() will undoubtedly result in
further uses of function.

Reported-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: cyphar@cyphar.com
Cc: keescook@chromium.org
Cc: linux@rasmusvillemoes.dk
Fixes: f5a1a536fa ("lib: introduce copy_struct_from_user() helper")
Link: https://lkml.kernel.org/r/20191021131149.GA19358@hirez.programming.kicks-ass.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31 16:44:25 +01:00
Greg Kroah-Hartman
9b7935f72f lib: raid6: fix awk build warnings
commit 702600eef73033ddd4eafcefcbb6560f3e3a90f7 upstream.

Newer versions of awk spit out these fun warnings:
	awk: ../lib/raid6/unroll.awk:16: warning: regexp escape sequence `\#' is not a known regexp operator

As commit 700c1018b86d ("x86/insn: Fix awk regexp warnings") showed, it
turns out that there are a number of awk strings that do not need to be
escaped and newer versions of awk now warn about this.

Fix the string up so that no warning is produced.  The exact same kernel
module gets created before and after this patch, showing that it wasn't
needed.

Link: https://lore.kernel.org/r/20191206152600.GA75093@kroah.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-12-17 19:56:09 +01:00
Jan Kiszka
3dcec0005a mm: Re-export ioremap_page_range
We need this in Jailhouse to map at specific virtual addresses, at
least for the moment.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
(cherry picked from commit 94bb285491a9a9e15c82c0761505b1073d6b7a47)
2019-11-25 15:46:59 +08:00
Lasse Collin
8e20ba2e53 lib/xz: fix XZ_DYNALLOC to avoid useless memory reallocations
s->dict.allocated was initialized to 0 but never set after a successful
allocation, thus the code always thought that the dictionary buffer has
to be reallocated.

Link: http://lkml.kernel.org/r/20191104185107.3b6330df@tukaani.org
Signed-off-by: Lasse Collin <lasse.collin@tukaani.org>
Reported-by: Yu Sun <yusun2@cisco.com>
Acked-by: Daniel Walker <danielwa@cisco.com>
Cc: "Yixia Si (yisi)" <yisi@cisco.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-11-15 18:34:00 -08:00
Corentin Labbe
820b7c717f lib: Remove select of inexistant GENERIC_IO
config option GENERIC_IO was removed but still selected by lib/kconfig
This patch finish the cleaning.

Fixes: 9de8da4774 ("kconfig: kill off GENERIC_IO option")
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-11-10 10:38:43 -08:00
Linus Torvalds
410ef736a7 XArray updates for 5.4
These patches all fix various bugs, some of which people have tripped
 over and some of which have been caught by automatic tools.
 
 Matthew Wilcox (Oracle) (5):
   XArray: Fix xas_next() with a single entry at 0
   idr: Fix idr_get_next_ul race with idr_remove
   radix tree: Remove radix_tree_iter_find
   idr: Fix integer overflow in idr_for_each_entry
   idr: Fix idr_alloc_u32 on 32-bit systems
 -----BEGIN PGP SIGNATURE-----
 
 iQEzBAABCgAdFiEEejHryeLBw/spnjHrDpNsjXcpgj4FAl3E4tgACgkQDpNsjXcp
 gj7YjQf6ArvGGHp3U+w1TRA4KCIrtUdGY4nceDQSYaJ2IVus+fHDQnwMCJb5Rjzw
 3aFZKLrrsaWWGKTqqRDKD4zm6I6Mg1239WNCnJ8VQrSRepNQ7WxVXGFn560NDZ5b
 u7zYXBm3CtlJpkX9JVbokii4LkjuwXzbuSh6cv+X3APBUQ3JXuGBmT7p2PLp0ol9
 lNKUrxZCK+CJ7kJo5W81lCzZc6GY2USqwmuqudGACWMm1K24TRL52PeD8NU6IzKc
 Mw9c7Osa0TlwjSaxObaRgLYzIZQoNbkrMTg0xNr8GZjJIn/yJIxqOBb4k3mZWQF1
 5KmLfpLotItt25MP8jxgx+1N03jjvw==
 =h6eN
 -----END PGP SIGNATURE-----

Merge tag 'xarray-5.4' of git://git.infradead.org/users/willy/linux-dax

Pull XArray fixes from Matthew Wilcox:
 "These all fix various bugs, some of which people have tripped over and
  some of which have been caught by automatic tools"

* tag 'xarray-5.4' of git://git.infradead.org/users/willy/linux-dax:
  idr: Fix idr_alloc_u32 on 32-bit systems
  idr: Fix integer overflow in idr_for_each_entry
  radix tree: Remove radix_tree_iter_find
  idr: Fix idr_get_next_ul race with idr_remove
  XArray: Fix xas_next() with a single entry at 0
2019-11-08 08:46:49 -08:00
Kevin Hao
5cbf2fff3b dump_stack: avoid the livelock of the dump_lock
In the current code, we use the atomic_cmpxchg() to serialize the output
of the dump_stack(), but this implementation suffers the thundering herd
problem.  We have observed such kind of livelock on a Marvell cn96xx
board(24 cpus) when heavily using the dump_stack() in a kprobe handler.
Actually we can let the competitors to wait for the releasing of the
lock before jumping to atomic_cmpxchg().  This will definitely mitigate
the thundering herd problem.  Thanks Linus for the suggestion.

[akpm@linux-foundation.org: fix comment]
Link: http://lkml.kernel.org/r/20191030031637.6025-1-haokexin@gmail.com
Fixes: b58d977432 ("dump_stack: serialize the output from dump_stack()")
Signed-off-by: Kevin Hao <haokexin@gmail.com>
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-11-06 08:47:50 -08:00
Matthew Wilcox (Oracle)
b7e9728f3d idr: Fix idr_alloc_u32 on 32-bit systems
Attempting to allocate an entry at 0xffffffff when one is already
present would succeed in allocating one at 2^32, which would confuse
everything.  Return -ENOSPC in this case, as expected.

Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
2019-11-03 06:36:50 -05:00
Matthew Wilcox (Oracle)
5a74ac4c4a idr: Fix idr_get_next_ul race with idr_remove
Commit 5c089fd0c7 ("idr: Fix idr_get_next race with idr_remove")
neglected to fix idr_get_next_ul().  As far as I can tell, nobody's
actually using this interface under the RCU read lock, but fix it now
before anybody decides to use it.

Fixes: 5c089fd0c7 ("idr: Fix idr_get_next race with idr_remove")
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
2019-11-01 22:26:34 -04:00
Thomas Gleixner
1638b8f096 lib/vdso: Make clock_getres() POSIX compliant again
A recent commit removed the NULL pointer check from the clock_getres()
implementation causing a test case to fault.

POSIX requires an explicit NULL pointer check for clock_getres() aside of
the validity check of the clock_id argument for obscure reasons.

Add it back for both 32bit and 64bit.

Note, this is only a partial revert of the offending commit which does not
bring back the broken fallback invocation in the the 32bit compat
implementations of clock_getres() and clock_gettime().

Fixes: a9446a906f ("lib/vdso/32: Remove inconsistent NULL pointer checks")
Reported-by: Andreas Schwab <schwab@linux-m68k.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/alpine.DEB.2.21.1910211202260.1904@nanos.tec.linutronix.de
2019-10-23 14:48:23 +02:00
Linus Torvalds
8eb4b3b0dd copy-struct-from-user-v5.4-rc4
-----BEGIN PGP SIGNATURE-----
 
 iHUEABYKAB0WIQRAhzRXHqcMeLMyaSiRxhvAZXjcogUCXacV8gAKCRCRxhvAZXjc
 oqaZAQDG+ziyN6umUemQPEX1Ar+FOJPIwDrEJdMRmoz3ozTFQAEA0RxquU3LkVnR
 Rx9wX07ObZB5nMi/V4yANpuH7Vbzrg4=
 =7JJk
 -----END PGP SIGNATURE-----

Merge tag 'copy-struct-from-user-v5.4-rc4' of gitolite.kernel.org:pub/scm/linux/kernel/git/brauner/linux

Pull usercopy test fixlets from Christian Brauner:
 "This contains two improvements for the copy_struct_from_user() tests:

   - a coding style change to get rid of the ugly "if ((ret |= test()))"
     pointed out when pulling the original patchset.

   - avoid a soft lockups when running the usercopy tests on machines
     with large page sizes by scanning only a 1024 byte region"

* tag 'copy-struct-from-user-v5.4-rc4' of gitolite.kernel.org:pub/scm/linux/kernel/git/brauner/linux:
  usercopy: Avoid soft lockups in test_check_nonzero_user()
  lib: test_user_copy: style cleanup
2019-10-18 18:19:04 -04:00
Michael Ellerman
f418dddffc
usercopy: Avoid soft lockups in test_check_nonzero_user()
On a machine with a 64K PAGE_SIZE, the nested for loops in
test_check_nonzero_user() can lead to soft lockups, eg:

  watchdog: BUG: soft lockup - CPU#4 stuck for 22s! [modprobe:611]
  Modules linked in: test_user_copy(+) vmx_crypto gf128mul crc32c_vpmsum virtio_balloon ip_tables x_tables autofs4
  CPU: 4 PID: 611 Comm: modprobe Tainted: G             L    5.4.0-rc1-gcc-8.2.0-00001-gf5a1a536fa14-dirty #1151
  ...
  NIP __might_sleep+0x20/0xc0
  LR  __might_fault+0x40/0x60
  Call Trace:
    check_zeroed_user+0x12c/0x200
    test_user_copy_init+0x67c/0x1210 [test_user_copy]
    do_one_initcall+0x60/0x340
    do_init_module+0x7c/0x2f0
    load_module+0x2d94/0x30e0
    __do_sys_finit_module+0xc8/0x150
    system_call+0x5c/0x68

Even with a 4K PAGE_SIZE the test takes multiple seconds. Instead
tweak it to only scan a 1024 byte region, but make it cross the
page boundary.

Fixes: f5a1a536fa ("lib: introduce copy_struct_from_user() helper")
Suggested-by: Aleksa Sarai <cyphar@cyphar.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Reviewed-by: Aleksa Sarai <cyphar@cyphar.com>
Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
Link: https://lore.kernel.org/r/20191016122732.13467-1-mpe@ellerman.id.au
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
2019-10-16 14:56:21 +02:00
Alexander Potapenko
03a9349ac0 lib/test_meminit: add a kmem_cache_alloc_bulk() test
Make sure allocations from kmem_cache_alloc_bulk() and
kmem_cache_free_bulk() are properly initialized.

Link: http://lkml.kernel.org/r/20191007091605.30530-2-glider@google.com
Signed-off-by: Alexander Potapenko <glider@google.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Christoph Lameter <cl@linux.com>
Cc: Laura Abbott <labbott@redhat.com>
Cc: Thibaut Sautereau <thibaut@sautereau.fr>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-10-14 15:04:01 -07:00