Re: [PATCH] lockdep: avoid signed overflow

[Ingo Molnar <mingo@kernel.org>]

* Mark Rutland <mark.rutland@arm.com> wrote:

> The counters in struct lockdep_stats are all (signed) ints. For some
> counters (e.g. hardirqs_on_events, hardirqs_off_events), it's easy to
> trigger an overflow in a short period of time, rendering the information
> exposed under /proc/lockdep_stats erroneous, and causing UBSAN to
> scream.

> diff --git a/kernel/locking/lockdep_internals.h b/kernel/locking/lockdep_internals.h
> index c2b8849..9fd970e 100644
> --- a/kernel/locking/lockdep_internals.h
> +++ b/kernel/locking/lockdep_internals.h
> @@ -132,23 +132,23 @@ extern void get_usage_chars(struct lock_class *class,
>   * and we want to avoid too much cache bouncing.
>   */
>  struct lockdep_stats {
> -	int	chain_lookup_hits;
> -	int	chain_lookup_misses;
> -	int	hardirqs_on_events;
> -	int	hardirqs_off_events;
> -	int	redundant_hardirqs_on;
> -	int	redundant_hardirqs_off;
> -	int	softirqs_on_events;
> -	int	softirqs_off_events;
> -	int	redundant_softirqs_on;
> -	int	redundant_softirqs_off;
> -	int	nr_unused_locks;
> -	int	nr_cyclic_checks;
> -	int	nr_cyclic_check_recursions;
> -	int	nr_find_usage_forwards_checks;
> -	int	nr_find_usage_forwards_recursions;
> -	int	nr_find_usage_backwards_checks;
> -	int	nr_find_usage_backwards_recursions;
> +	unsigned long	chain_lookup_hits;
> +	unsigned long	chain_lookup_misses;
> +	unsigned long	hardirqs_on_events;
> +	unsigned long	hardirqs_off_events;
> +	unsigned long	redundant_hardirqs_on;
> +	unsigned long	redundant_hardirqs_off;
> +	unsigned long	softirqs_on_events;
> +	unsigned long	softirqs_off_events;
> +	unsigned long	redundant_softirqs_on;
> +	unsigned long	redundant_softirqs_off;
> +	unsigned long	nr_unused_locks;
> +	unsigned long	nr_cyclic_checks;
> +	unsigned long	nr_cyclic_check_recursions;
> +	unsigned long	nr_find_usage_forwards_checks;
> +	unsigned long	nr_find_usage_forwards_recursions;
> +	unsigned long	nr_find_usage_backwards_checks;
> +	unsigned long	nr_find_usage_backwards_recursions;

Presumably it's just as easy to overflow on 32-bit CPUs, so this should probably 
be u64 or such.

Thanks,

	Ingo