linux-kernel - Re: [PATCH 3/9] Remove unused header <linux/cnt32_to

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <s9qss5o-3330-n3n3-no59-q9p5883o8o1@syhkavp.arg>
Date:   Tue, 2 Nov 2021 19:16:59 -0400 (EDT)
From:   Nicolas Pitre <nico@...xnic.net>
To:     Jonathan Corbet <corbet@....net>
cc:     linux-kernel@...r.kernel.org, Mike Rapoport <rppt@...nel.org>,
        Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCH 3/9] Remove unused header <linux/cnt32_to_63.h>

On Tue, 2 Nov 2021, Jonathan Corbet wrote:

> Commit fb37409a01b0 ("arch: remove unicore32 port) deleted the last file
> that included <linux/cnt32_to_63.h>, but left that header file behind.
> Nothing uses it, delete it now.
> 
> Cc: Nicolas Pitre <npitre@...libre.com>
> Cc: Mike Rapoport <rppt@...nel.org>
> Cc: Arnd Bergmann <arnd@...db.de>
> Signed-off-by: Jonathan Corbet <corbet@....net>

Acked-by: Nicolas Pitre <nico@...xnic.net>

> ---
>  include/linux/cnt32_to_63.h | 104 ------------------------------------
>  1 file changed, 104 deletions(-)
>  delete mode 100644 include/linux/cnt32_to_63.h
> 
> diff --git a/include/linux/cnt32_to_63.h b/include/linux/cnt32_to_63.h
> deleted file mode 100644
> index 064428479f2d..000000000000
> --- a/include/linux/cnt32_to_63.h
> +++ /dev/null
> @@ -1,104 +0,0 @@
> -/* SPDX-License-Identifier: GPL-2.0-only */
> -/*
> - *  Extend a 32-bit counter to 63 bits
> - *
> - *  Author:	Nicolas Pitre
> - *  Created:	December 3, 2006
> - *  Copyright:	MontaVista Software, Inc.
> - */
> -
> -#ifndef __LINUX_CNT32_TO_63_H__
> -#define __LINUX_CNT32_TO_63_H__
> -
> -#include <linux/compiler.h>
> -#include <linux/types.h>
> -#include <asm/byteorder.h>
> -
> -/* this is used only to give gcc a clue about good code generation */
> -union cnt32_to_63 {
> -	struct {
> -#if defined(__LITTLE_ENDIAN)
> -		u32 lo, hi;
> -#elif defined(__BIG_ENDIAN)
> -		u32 hi, lo;
> -#endif
> -	};
> -	u64 val;
> -};
> -
> -
> -/**
> - * cnt32_to_63 - Expand a 32-bit counter to a 63-bit counter
> - * @cnt_lo: The low part of the counter
> - *
> - * Many hardware clock counters are only 32 bits wide and therefore have
> - * a relatively short period making wrap-arounds rather frequent.  This
> - * is a problem when implementing sched_clock() for example, where a 64-bit
> - * non-wrapping monotonic value is expected to be returned.
> - *
> - * To overcome that limitation, let's extend a 32-bit counter to 63 bits
> - * in a completely lock free fashion. Bits 0 to 31 of the clock are provided
> - * by the hardware while bits 32 to 62 are stored in memory.  The top bit in
> - * memory is used to synchronize with the hardware clock half-period.  When
> - * the top bit of both counters (hardware and in memory) differ then the
> - * memory is updated with a new value, incrementing it when the hardware
> - * counter wraps around.
> - *
> - * Because a word store in memory is atomic then the incremented value will
> - * always be in synch with the top bit indicating to any potential concurrent
> - * reader if the value in memory is up to date or not with regards to the
> - * needed increment.  And any race in updating the value in memory is harmless
> - * as the same value would simply be stored more than once.
> - *
> - * The restrictions for the algorithm to work properly are:
> - *
> - * 1) this code must be called at least once per each half period of the
> - *    32-bit counter;
> - *
> - * 2) this code must not be preempted for a duration longer than the
> - *    32-bit counter half period minus the longest period between two
> - *    calls to this code;
> - *
> - * Those requirements ensure proper update to the state bit in memory.
> - * This is usually not a problem in practice, but if it is then a kernel
> - * timer should be scheduled to manage for this code to be executed often
> - * enough.
> - *
> - * And finally:
> - *
> - * 3) the cnt_lo argument must be seen as a globally incrementing value,
> - *    meaning that it should be a direct reference to the counter data which
> - *    can be evaluated according to a specific ordering within the macro,
> - *    and not the result of a previous evaluation stored in a variable.
> - *
> - * For example, this is wrong:
> - *
> - *	u32 partial = get_hw_count();
> - *	u64 full = cnt32_to_63(partial);
> - *	return full;
> - *
> - * This is fine:
> - *
> - *	u64 full = cnt32_to_63(get_hw_count());
> - *	return full;
> - *
> - * Note that the top bit (bit 63) in the returned value should be considered
> - * as garbage.  It is not cleared here because callers are likely to use a
> - * multiplier on the returned value which can get rid of the top bit
> - * implicitly by making the multiplier even, therefore saving on a runtime
> - * clear-bit instruction. Otherwise caller must remember to clear the top
> - * bit explicitly.
> - */
> -#define cnt32_to_63(cnt_lo) \
> -({ \
> -	static u32 __m_cnt_hi; \
> -	union cnt32_to_63 __x; \
> -	__x.hi = __m_cnt_hi; \
> - 	smp_rmb(); \
> -	__x.lo = (cnt_lo); \
> -	if (unlikely((s32)(__x.hi ^ __x.lo) < 0)) \
> -		__m_cnt_hi = __x.hi = (__x.hi ^ 0x80000000) + (__x.hi >> 31); \
> -	__x.val; \
> -})
> -
> -#endif
> -- 
> 2.31.1
> 
>