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: <CANpmjNOsVYG8+w64pPrAiDm23WPHnH1-7hFHFgMmKPxeqL7yYg@mail.gmail.com>
Date: Mon, 24 Jun 2024 16:41:09 +0200
From: Marco Elver <elver@...gle.com>
To: Alexey Dobriyan <adobriyan@...il.com>
Cc: Thomas Gleixner <tglx@...utronix.de>, linux-kernel@...r.kernel.org, 
	akpm@...ux-foundation.org
Subject: Re: [PATCH] compiler.h: simplify data_race() macro

On Mon, 24 Jun 2024 at 16:38, Alexey Dobriyan <adobriyan@...il.com> wrote:
>
> On Mon, Jun 24, 2024 at 02:27:43PM +0200, Marco Elver wrote:
> > On Mon, 24 Jun 2024 at 13:49, Alexey Dobriyan <adobriyan@...il.com> wrote:
> > >
> > > Use auto type deduction and comma expression to decrease macro expansion
> > > size.
> > >
> > > __unqual_scalar_typeof() is quite wordy macro by itself.
> > >
> > > "expr" can be arbitrary complex so not expanding it twice is good.
> > > Should be faster too because type is deduced only once
> > > from the initializer.
> > >
> > > Signed-off-by: Alexey Dobriyan <adobriyan@...il.com>
> >
> > Thanks for cleaning up.  That code certainly predates the availability
> > of __auto_type. Although if I recall correctly, __unqual_scalar_typeof
> > became the first user of _Generic (the first C11 keyword we used in
> > the kernel?), but we used some ifdef to still support ancient
> > compilers initially (that definitely also didn't have __auto_type).
> >
> > Reviewed-by: Marco Elver <elver@...gle.com>
> >
> > Which tree is this for?
>
> This is against mainline. Should not really matter, -next has the same code.

I meant which maintainer/tree should pick this up?

> > > --- a/include/linux/compiler.h
> > > +++ b/include/linux/compiler.h
> > > @@ -200,10 +200,7 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val,
> > >   */
> > >  #define data_race(expr)                                                        \
> > >  ({                                                                     \
> > > -       __unqual_scalar_typeof(({ expr; })) __v = ({                    \
> > > -               __kcsan_disable_current();                              \
> > > -               expr;                                                   \
> > > -       });                                                             \
> > > +       __auto_type __v = (__kcsan_disable_current(), expr);            \
> > >         __kcsan_enable_current();                                       \
> > >         __v;                                                            \
> > >  })

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ