linux.git/lib, branch v5.4.219

lib/vdso: Mark do_hres() and do_coarse() as __always_inline

2022-09-05T08:27:47+00:00

[ Upstream commit c966533f8c6c45f93c52599f8460e7695f0b7eaa ]

Performance numbers for Intel(R) Core(TM) i5-6300U CPU @ 2.40GHz
(more clock_gettime() cycles - the better):

clock            | before     | after      | diff
----------------------------------------------------------
monotonic        |  153222105 |  166775025 | 8.8%
monotonic-coarse |  671557054 |  691513017 | 3.0%
monotonic-raw    |  147116067 |  161057395 | 9.5%
boottime         |  153446224 |  166962668 | 9.1%

The improvement for arm64 for monotonic and boottime is around 3.5%.

clock            | before     | after      | diff
==================================================
monotonic          17326692     17951770     3.6%
monotonic-coarse   43624027     44215292     1.3%
monotonic-raw      17541809     17554932     0.1%
boottime           17334982     17954361     3.5%

[ tglx: Avoid the goto ]

Signed-off-by: Andrei Vagin 
Signed-off-by: Dmitry Safonov 
Signed-off-by: Thomas Gleixner 
Link: https://lore.kernel.org/r/20191112012724.250792-3-dima@arista.com
Signed-off-by: Sasha Levin

lib/vdso: Let do_coarse() return 0 to simplify the callsite

2022-09-05T08:27:47+00:00

[ Upstream commit 8463cf80529d0fd80b84cd5ab8b9b952b01c7eb9 ]

do_coarse() is similar to do_hres() except that it never fails.

Change its type to int instead of void and let it always return success (0)
to simplify the call site.

Signed-off-by: Christophe Leroy 
Signed-off-by: Thomas Gleixner 
Link: https://lore.kernel.org/r/21e8afa38c02ca8672c2690307383507fe63b454.1577111367.git.christophe.leroy@c-s.fr
Signed-off-by: Sasha Levin

ratelimit: Fix data-races in ___ratelimit().

2022-09-05T08:27:42+00:00

[ Upstream commit 6bae8ceb90ba76cdba39496db936164fa672b9be ]

While reading rs->interval and rs->burst, they can be changed
concurrently via sysctl (e.g. net_ratelimit_state).  Thus, we
need to add READ_ONCE() to their readers.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Kuniyuki Iwashima 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

lib/list_debug.c: Detect uninitialized lists

2022-08-25T09:18:36+00:00

[ Upstream commit 0cc011c576aaa4de505046f7a6c90933d7c749a9 ]

In some circumstances, attempts are made to add entries to or to remove
entries from an uninitialized list.  A prime example is
amdgpu_bo_vm_destroy(): It is indirectly called from
ttm_bo_init_reserved() if that function fails, and tries to remove an
entry from a list.  However, that list is only initialized in
amdgpu_bo_create_vm() after the call to ttm_bo_init_reserved() returned
success.  This results in crashes such as

 BUG: kernel NULL pointer dereference, address: 0000000000000000
 #PF: supervisor read access in kernel mode
 #PF: error_code(0x0000) - not-present page
 PGD 0 P4D 0
 Oops: 0000 [#1] PREEMPT SMP NOPTI
 CPU: 1 PID: 1479 Comm: chrome Not tainted 5.10.110-15768-g29a72e65dae5
 Hardware name: Google Grunt/Grunt, BIOS Google_Grunt.11031.149.0 07/15/2020
 RIP: 0010:__list_del_entry_valid+0x26/0x7d
 ...
 Call Trace:
  amdgpu_bo_vm_destroy+0x48/0x8b
  ttm_bo_init_reserved+0x1d7/0x1e0
  amdgpu_bo_create+0x212/0x476
  ? amdgpu_bo_user_destroy+0x23/0x23
  ? kmem_cache_alloc+0x60/0x271
  amdgpu_bo_create_vm+0x40/0x7d
  amdgpu_vm_pt_create+0xe8/0x24b
 ...

Check if the list's prev and next pointers are NULL to catch such problems.

Link: https://lkml.kernel.org/r/20220531222951.92073-1-linux@roeck-us.net
Signed-off-by: Guenter Roeck 
Cc: Steven Rostedt 
Signed-off-by: Andrew Morton 
Signed-off-by: Sasha Levin

locking/refcount: Consolidate implementations of refcount_t

2022-07-29T15:14:17+00:00

[ Upstream commit fb041bb7c0a918b95c6889fc965cdc4a75b4c0ca ]

The generic implementation of refcount_t should be good enough for
everybody, so remove ARCH_HAS_REFCOUNT and REFCOUNT_FULL entirely,
leaving the generic implementation enabled unconditionally.

Signed-off-by: Will Deacon 
Reviewed-by: Ard Biesheuvel 
Acked-by: Kees Cook 
Tested-by: Hanjun Guo 
Cc: Ard Biesheuvel 
Cc: Elena Reshetova 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: https://lkml.kernel.org/r/20191121115902.2551-9-will@kernel.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin

locking/refcount: Move saturation warnings out of line

2022-07-29T15:14:17+00:00

[ Upstream commit 1eb085d94256aaa69b00cf5a86e3c5f5bb2bc460 ]

Having the refcount saturation and warnings inline bloats the text,
despite the fact that these paths should never be executed in normal
operation.

Move the refcount saturation and warnings out of line to reduce the
image size when refcount_t checking is enabled. Relative to an x86_64
defconfig, the sizes reported by bloat-o-meter are:

 # defconfig+REFCOUNT_FULL, inline saturation (i.e. before this patch)
 Total: Before=14762076, After=14915442, chg +1.04%

 # defconfig+REFCOUNT_FULL, out-of-line saturation (i.e. after this patch)
 Total: Before=14762076, After=14835497, chg +0.50%

A side-effect of this change is that we now only get one warning per
refcount saturation type, rather than one per problematic call-site.

Signed-off-by: Will Deacon 
Reviewed-by: Ard Biesheuvel 
Reviewed-by: Kees Cook 
Tested-by: Hanjun Guo 
Cc: Ard Biesheuvel 
Cc: Elena Reshetova 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: https://lkml.kernel.org/r/20191121115902.2551-7-will@kernel.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin

locking/refcount: Move the bulk of the REFCOUNT_FULL implementation into the header

2022-07-29T15:14:17+00:00

[ Upstream commit 77e9971c79c29542ab7dd4140f9343bf2ff36158 ]

In an effort to improve performance of the REFCOUNT_FULL implementation,
move the bulk of its functions into linux/refcount.h. This allows them
to be inlined in the same way as if they had been provided via
CONFIG_ARCH_HAS_REFCOUNT.

Signed-off-by: Will Deacon 
Reviewed-by: Ard Biesheuvel 
Reviewed-by: Kees Cook 
Tested-by: Hanjun Guo 
Cc: Ard Biesheuvel 
Cc: Elena Reshetova 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: https://lkml.kernel.org/r/20191121115902.2551-5-will@kernel.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin

locking/refcount: Remove unused refcount_*_checked() variants

2022-07-29T15:14:17+00:00

[ Upstream commit 7221762c48c6bbbcc6cc51d8b803c06930215e34 ]

The full-fat refcount implementation is exposed via a set of functions
suffixed with "_checked()", the idea being that code can choose to use
the more expensive, yet more secure implementation on a case-by-case
basis.

In reality, this hasn't happened, so with a grand total of zero users,
let's remove the checked variants for now by simply dropping the suffix
and predicating the out-of-line functions on CONFIG_REFCOUNT_FULL=y.

Signed-off-by: Will Deacon 
Reviewed-by: Ard Biesheuvel 
Reviewed-by: Kees Cook 
Tested-by: Hanjun Guo 
Cc: Ard Biesheuvel 
Cc: Elena Reshetova 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: https://lkml.kernel.org/r/20191121115902.2551-4-will@kernel.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin

locking/refcount: Ensure integer operands are treated as signed

2022-07-29T15:14:16+00:00

[ Upstream commit 97a1420adf0cdf0cf6f41bab0b2acf658c96b94b ]

In preparation for changing the saturation point of REFCOUNT_FULL to
INT_MIN/2, change the type of integer operands passed into the API
from 'unsigned int' to 'int' so that we can avoid casting during
comparisons when we don't want to fall foul of C integral conversion
rules for signed and unsigned types.

Since the kernel is compiled with '-fno-strict-overflow', we don't need
to worry about the UB introduced by signed overflow here. Furthermore,
we're already making heavy use of the atomic_t API, which operates
exclusively on signed types.

Signed-off-by: Will Deacon 
Reviewed-by: Ard Biesheuvel 
Reviewed-by: Kees Cook 
Tested-by: Hanjun Guo 
Cc: Ard Biesheuvel 
Cc: Elena Reshetova 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: https://lkml.kernel.org/r/20191121115902.2551-3-will@kernel.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin

locking/refcount: Define constants for saturation and max refcount values

2022-07-29T15:14:16+00:00

[ Upstream commit 23e6b169c9917fbd77534f8c5f378cb073f548bd ]

The REFCOUNT_FULL implementation uses a different saturation point than
the x86 implementation, which means that the shared refcount code in
lib/refcount.c (e.g. refcount_dec_not_one()) needs to be aware of the
difference.

Rather than duplicate the definitions from the lkdtm driver, instead
move them into  and update all references accordingly.

Signed-off-by: Will Deacon 
Reviewed-by: Ard Biesheuvel 
Reviewed-by: Kees Cook 
Tested-by: Hanjun Guo 
Cc: Ard Biesheuvel 
Cc: Elena Reshetova 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: https://lkml.kernel.org/r/20191121115902.2551-2-will@kernel.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin