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: <20200727230323.GA3390623@google.com>
Date:   Mon, 27 Jul 2020 19:03:23 -0400
From:   Joel Fernandes <joel@...lfernandes.org>
To:     Boqun Feng <boqun.feng@...il.com>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Josh Triplett <josh@...htriplett.org>,
        Lai Jiangshan <jiangshanlai@...il.com>,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        "Paul E. McKenney" <paulmck@...nel.org>, rcu <rcu@...r.kernel.org>,
        Will Deacon <will@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH RFC v2] rcu/segcblist: Add counters to segcblist
 datastructure

On Mon, Jul 27, 2020 at 09:49:25PM +0800, Boqun Feng wrote:
[...] 
> So C11 features are available to gnu89 as extensions, also I tried to
> compile the following code with -std=gnu89:
> 
> 	#include <stdio.h>
> 
> 	typedef struct {
> 		int a;
> 	} atomic_t;
> 
> 	void g(void) {
> 		printf("this is g\n");
> 	}
> 
> 	void h(void) {
> 		printf("this is f\n");
> 	}
> 
> 	#define gen(x) _Generic((x), atomic_t : h(), int : g())
> 
> 	int main(void) {
> 		int a;
> 		atomic_t b;
> 		gen(a);
> 		gen(b);
> 		gen(b);
> 	}
> 
> , and it worked.
> 
> Besides, please note that in include/linux/compiler_types.h, _Generic is
> already used.

> > > With these primitives introduced, you can avoid () to add those
> > > rcu_segcblist_*_seglen() which have #ifdefs in them. Of course, an
> > > alternative would be that we implement rcu_segcblist_*_seglen() using
> > > _Generic, but I think someone else may have the similar problems or
> > > requirement (already or in the future), so it might be worthwhile to
> > > introduce the gen_ primitives for broader usage.
> > 
> > One issue is code using memory barriers around the operation, such as
> > in rcu_segcblist_add_len() where you use smp_mb__before_atomic() for
> > the atomic version, and regular smp_mb() for the non-atomic version.
> > So ifdef will still exist to some degree.
> > 
> 
> Right, I think we can have two functions: long_add_mb() and
> atomic_long_add_mb(), this part is similar to ifdef approach, but we can
> make a gen_long_add_mb() based on these two functions, and
> gen_long_add_mb() simply switches between those functions according to
> the actual type of the field, which I think is better than ifdef
> approach at readability and maintenance.

Thanks for clarification. I agree with your idea, would you be able to write
a patch to add the helpers my patch can use?

If others are Ok with your idea, I can go ahead and use your helpers.

(I could write the helpers myself as well, next time I send the patch).

thanks,

 - Joel

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ