* Andrey Ryabinin <aryabi...@virtuozzo.com> wrote:

> +#define __READ_ONCE_SIZE                                             \
> +({                                                                   \
> +     switch (size) {                                                 \
> +     case 1: *(__u8 *)res = *(volatile __u8 *)p; break;              \
> +     case 2: *(__u16 *)res = *(volatile __u16 *)p; break;            \
> +     case 4: *(__u32 *)res = *(volatile __u32 *)p; break;            \
> +     case 8: *(__u64 *)res = *(volatile __u64 *)p; break;            \
> +     default:                                                        \
> +             barrier();                                              \
> +             __builtin_memcpy((void *)res, (const void *)p, size);   \
> +             barrier();                                              \
> +     }                                                               \
> +})
> +
> +static __always_inline
> +void __read_once_size_check(const volatile void *p, void *res, int size)
>  {
> +     __READ_ONCE_SIZE;
>  }

> +#ifdef CONFIG_KASAN
> +static __no_sanitize_address __maybe_unused
> +void __read_once_size_nocheck(const volatile void *p, void *res, int size)
> +{
> +     __READ_ONCE_SIZE;
> +}
> +#else
> +static __always_inline __alias(__read_once_size_check)
> +void __read_once_size_nocheck(const volatile void *p, void *res, int size);
> +#endif

> +#define __READ_ONCE(x, check)                                \
> +({                                                           \
> +     union { typeof(x) __val; char __c[1]; } __u;            \
> +     __read_once_size##check(&(x), __u.__c, sizeof(x));      \
> +     __u.__val;                                              \
> +})
> +#define READ_ONCE(x) __READ_ONCE(x, _check)
> +#define READ_ONCE_NOCHECK(x) __READ_ONCE(x, _nocheck)

So all this code is quite convoluted, and as the changelog explains it's done 
to 
work around a GCC inlining + no-kasan bug.

But please explain this in the code as well, in a comment, so future 
generations 
are not kept wondering why these relatively simple wrappers are coded in such 
an 
ugly and roundabout fashion.

Thanks,

        Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to