<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/lib, branch v5.4.7</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v5.4.7</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v5.4.7'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2019-12-31T15:44:25+00:00</updated>
<entry>
<title>ubsan, x86: Annotate and allow __ubsan_handle_shift_out_of_bounds() in uaccess regions</title>
<updated>2019-12-31T15:44:25+00:00</updated>
<author>
<name>Peter Zijlstra</name>
<email>peterz@infradead.org</email>
</author>
<published>2019-10-21T13:11:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=39303579ebc44edbb872334595e6979b4cc16e28'/>
<id>urn:sha1:39303579ebc44edbb872334595e6979b4cc16e28</id>
<content type='text'>
[ 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 &lt;rdunlap@infradead.org&gt;
Tested-by: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Signed-off-by: Peter Zijlstra (Intel) &lt;peterz@infradead.org&gt;
Acked-by: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Acked-by: Christian Brauner &lt;christian.brauner@ubuntu.com&gt;
Cc: Josh Poimboeuf &lt;jpoimboe@redhat.com&gt;
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Stephen Rothwell &lt;sfr@canb.auug.org.au&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: cyphar@cyphar.com
Cc: keescook@chromium.org
Cc: linux@rasmusvillemoes.dk
Fixes: f5a1a536fa14 ("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 &lt;mingo@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>lib: raid6: fix awk build warnings</title>
<updated>2019-12-17T18:56:09+00:00</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2019-12-06T15:26:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9b7935f72f9be674d2177c395f3cfb62283dc97e'/>
<id>urn:sha1:9b7935f72f9be674d2177c395f3cfb62283dc97e</id>
<content type='text'>
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 &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>lib/xz: fix XZ_DYNALLOC to avoid useless memory reallocations</title>
<updated>2019-11-16T02:34:00+00:00</updated>
<author>
<name>Lasse Collin</name>
<email>lasse.collin@tukaani.org</email>
</author>
<published>2019-11-16T01:34:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8e20ba2e53fc6198cbfbcc700e9f884157052a8d'/>
<id>urn:sha1:8e20ba2e53fc6198cbfbcc700e9f884157052a8d</id>
<content type='text'>
s-&gt;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 &lt;lasse.collin@tukaani.org&gt;
Reported-by: Yu Sun &lt;yusun2@cisco.com&gt;
Acked-by: Daniel Walker &lt;danielwa@cisco.com&gt;
Cc: "Yixia Si (yisi)" &lt;yisi@cisco.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>lib: Remove select of inexistant GENERIC_IO</title>
<updated>2019-11-10T18:38:43+00:00</updated>
<author>
<name>Corentin Labbe</name>
<email>clabbe@baylibre.com</email>
</author>
<published>2019-11-10T16:27:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=820b7c717f09ea5f024f2185e69e2847fd2851dd'/>
<id>urn:sha1:820b7c717f09ea5f024f2185e69e2847fd2851dd</id>
<content type='text'>
config option GENERIC_IO was removed but still selected by lib/kconfig
This patch finish the cleaning.

Fixes: 9de8da47742b ("kconfig: kill off GENERIC_IO option")
Acked-by: Rob Herring &lt;robh@kernel.org&gt;
Signed-off-by: Corentin Labbe &lt;clabbe@baylibre.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>Merge tag 'xarray-5.4' of git://git.infradead.org/users/willy/linux-dax</title>
<updated>2019-11-08T16:46:49+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2019-11-08T16:46:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=410ef736a77b584e1c54a3784ee56ca63114ce11'/>
<id>urn:sha1:410ef736a77b584e1c54a3784ee56ca63114ce11</id>
<content type='text'>
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
</content>
</entry>
<entry>
<title>dump_stack: avoid the livelock of the dump_lock</title>
<updated>2019-11-06T16:47:50+00:00</updated>
<author>
<name>Kevin Hao</name>
<email>haokexin@gmail.com</email>
</author>
<published>2019-11-06T05:16:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5cbf2fff3bba8d3c6a4d47c1754de1cf57e2b01f'/>
<id>urn:sha1:5cbf2fff3bba8d3c6a4d47c1754de1cf57e2b01f</id>
<content type='text'>
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: b58d977432c8 ("dump_stack: serialize the output from dump_stack()")
Signed-off-by: Kevin Hao &lt;haokexin@gmail.com&gt;
Suggested-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>idr: Fix idr_alloc_u32 on 32-bit systems</title>
<updated>2019-11-03T11:36:50+00:00</updated>
<author>
<name>Matthew Wilcox (Oracle)</name>
<email>willy@infradead.org</email>
</author>
<published>2019-11-02T04:25:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b7e9728f3d7fc5c5c8508d99f1675212af5cfd49'/>
<id>urn:sha1:b7e9728f3d7fc5c5c8508d99f1675212af5cfd49</id>
<content type='text'>
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) &lt;willy@infradead.org&gt;
</content>
</entry>
<entry>
<title>idr: Fix idr_get_next_ul race with idr_remove</title>
<updated>2019-11-02T02:26:34+00:00</updated>
<author>
<name>Matthew Wilcox (Oracle)</name>
<email>willy@infradead.org</email>
</author>
<published>2019-11-02T01:36:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5a74ac4c4a97bd8b7dba054304d598e2a882fea6'/>
<id>urn:sha1:5a74ac4c4a97bd8b7dba054304d598e2a882fea6</id>
<content type='text'>
Commit 5c089fd0c734 ("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: 5c089fd0c734 ("idr: Fix idr_get_next race with idr_remove")
Signed-off-by: Matthew Wilcox (Oracle) &lt;willy@infradead.org&gt;
</content>
</entry>
<entry>
<title>lib/vdso: Make clock_getres() POSIX compliant again</title>
<updated>2019-10-23T12:48:23+00:00</updated>
<author>
<name>Thomas Gleixner</name>
<email>tglx@linutronix.de</email>
</author>
<published>2019-10-21T10:07:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1638b8f096ca165965189b9626564c933c79fe63'/>
<id>urn:sha1:1638b8f096ca165965189b9626564c933c79fe63</id>
<content type='text'>
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: a9446a906f52 ("lib/vdso/32: Remove inconsistent NULL pointer checks")
Reported-by: Andreas Schwab &lt;schwab@linux-m68k.org&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Tested-by: Christophe Leroy &lt;christophe.leroy@c-s.fr&gt;
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/alpine.DEB.2.21.1910211202260.1904@nanos.tec.linutronix.de

</content>
</entry>
<entry>
<title>Merge tag 'copy-struct-from-user-v5.4-rc4' of gitolite.kernel.org:pub/scm/linux/kernel/git/brauner/linux</title>
<updated>2019-10-18T22:19:04+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2019-10-18T22:19:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8eb4b3b0dd9ae3e5399ff902da87d13740a2b70f'/>
<id>urn:sha1:8eb4b3b0dd9ae3e5399ff902da87d13740a2b70f</id>
<content type='text'>
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
</content>
</entry>
</feed>
