linux-stable.git/lib, branch v5.4.16

lib: Reduce user_access_begin() boundaries in strncpy_from_user() and strnlen_user()

2020-01-29T15:45:29+00:00

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: 594cc251fdd0 ("make 'user_access_begin()' do 'access_ok()'")
Signed-off-by: Christophe Leroy 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

XArray: Fix xas_find returning too many entries

2020-01-29T15:45:27+00:00

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) 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

XArray: Fix xa_find_after with multi-index entries

2020-01-29T15:45:26+00:00

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) 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

XArray: Fix infinite loop with entry at ULONG_MAX

2020-01-29T15:45:26+00:00

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) 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

sbitmap: only queue kyber's wait callback if not already active

2020-01-12T11:21:44+00:00

[ 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 
Signed-off-by: David Jeffery 
Reported-by: John Pittman 
Tested-by: John Pittman 
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin

lib/ubsan: don't serialize UBSAN report

2020-01-09T09:20:07+00:00

[ 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): [] _raw_spin_unlock_irqrestore+0x90/0xa0
  hardirqs last disabled at (6284): [] _raw_spin_lock_irqsave+0x30/0x78
  softirqs last  enabled at (2430): [] fpsimd_restore_current_state+0x60/0xe8
  softirqs last disabled at (2427): [] fpsimd_restore_current_state+0x28/0xe8
  Preemption disabled at:
  [] 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 
Reported-by: Andre Przywara 
Acked-by: Andrey Ryabinin 
Cc: Thomas Gleixner 
Cc: Sebastian Andrzej Siewior 
Cc: Steven Rostedt 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

ubsan, x86: Annotate and allow __ubsan_handle_shift_out_of_bounds() in uaccess regions

2019-12-31T15:44:25+00:00

[ 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 
Tested-by: Randy Dunlap 
Signed-off-by: Peter Zijlstra (Intel) 
Acked-by: Randy Dunlap 
Acked-by: Christian Brauner 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Stephen Rothwell 
Cc: Thomas Gleixner 
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 
Signed-off-by: Sasha Levin

lib: raid6: fix awk build warnings

2019-12-17T18:56:09+00:00

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

lib/xz: fix XZ_DYNALLOC to avoid useless memory reallocations

2019-11-16T02:34:00+00:00

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 
Reported-by: Yu Sun 
Acked-by: Daniel Walker 
Cc: "Yixia Si (yisi)" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

lib: Remove select of inexistant GENERIC_IO

2019-11-10T18:38:43+00:00

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 
Signed-off-by: Corentin Labbe 
Signed-off-by: Linus Torvalds