search for: barrier_stems

...mory barrier cleanup, this patchset extends checkpatch to make it easier to stop incorrect memory barrier usage. This replaces the checkpatch patches in my series arch: barrier cleanup + barriers for virt and will be included in the pull request including the series. changes from v3: rename smp_barrier_stems to barrier_stems as suggested by Julian Calaby. add (?: ... ) around a variable in regexp, in case we change the value later so that it matters. changes from v2: address comments by Joe Perches: use (?: ... ) to avoid unnecessary capture groups rename smp_barriers to smp_barrier_stems for cla...

...mory barrier cleanup, this patchset extends checkpatch to make it easier to stop incorrect memory barrier usage. This replaces the checkpatch patches in my series arch: barrier cleanup + barriers for virt and will be included in the pull request including the series. changes from v3: rename smp_barrier_stems to barrier_stems as suggested by Julian Calaby. add (?: ... ) around a variable in regexp, in case we change the value later so that it matters. changes from v2: address comments by Joe Perches: use (?: ... ) to avoid unnecessary capture groups rename smp_barriers to smp_barrier_stems for cla...

...it a/scripts/checkpatch.pl b/scripts/checkpatch.pl > [] > > > @@ -5133,7 +5133,8 @@ sub process { > > > ????????????????}x; > > > ????????????????my $all_barriers = qr{ > > > ????????????????????????$barriers| > > > -???????????????????????smp_(?:$smp_barrier_stems) > > > +???????????????????????smp_(?:$smp_barrier_stems)| > > > +???????????????????????virt_(?:$smp_barrier_stems) > > > > Sorry I'm late to the party here, but would it make sense to write this as: > > > > (?:smp|virt)_(?:$smp_barrier_stems) >...

...it a/scripts/checkpatch.pl b/scripts/checkpatch.pl > [] > > > @@ -5133,7 +5133,8 @@ sub process { > > > ????????????????}x; > > > ????????????????my $all_barriers = qr{ > > > ????????????????????????$barriers| > > > -???????????????????????smp_(?:$smp_barrier_stems) > > > +???????????????????????smp_(?:$smp_barrier_stems)| > > > +???????????????????????virt_(?:$smp_barrier_stems) > > > > Sorry I'm late to the party here, but would it make sense to write this as: > > > > (?:smp|virt)_(?:$smp_barrier_stems) >...

...atch.pl > index 15cfca4..4466579 100755 > --- a/scripts/checkpatch.pl > +++ b/scripts/checkpatch.pl > @@ -5133,7 +5133,8 @@ sub process { > }x; > my $all_barriers = qr{ > $barriers| > - smp_(?:$smp_barrier_stems) > + smp_(?:$smp_barrier_stems)| > + virt_(?:$smp_barrier_stems) Sorry I'm late to the party here, but would it make sense to write this as: (?:smp|virt)_(?:$smp_barrier_stems) Thanks, -- Julian Calaby Email: julian.calaby at gmail.com Pro...

...atch.pl > index 15cfca4..4466579 100755 > --- a/scripts/checkpatch.pl > +++ b/scripts/checkpatch.pl > @@ -5133,7 +5133,8 @@ sub process { > }x; > my $all_barriers = qr{ > $barriers| > - smp_(?:$smp_barrier_stems) > + smp_(?:$smp_barrier_stems)| > + virt_(?:$smp_barrier_stems) Sorry I'm late to the party here, but would it make sense to write this as: (?:smp|virt)_(?:$smp_barrier_stems) Thanks, -- Julian Calaby Email: julian.calaby at gmail.com Pro...

...; >> [] > >> > > @@ -5133,7 +5133,8 @@ sub process { > >> > > }x; > >> > > my $all_barriers = qr{ > >> > > $barriers| > >> > > - smp_(?:$smp_barrier_stems) > >> > > + smp_(?:$smp_barrier_stems)| > >> > > + virt_(?:$smp_barrier_stems) > >> > > >> > Sorry I'm late to the party here, but would it make sense to write this as: > >> > > >...

...comment. [] > > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl [] > > @@ -5133,7 +5133,8 @@ sub process { > > ????????????????}x; > > ????????????????my $all_barriers = qr{ > > ????????????????????????$barriers| > > -???????????????????????smp_(?:$smp_barrier_stems) > > +???????????????????????smp_(?:$smp_barrier_stems)| > > +???????????????????????virt_(?:$smp_barrier_stems) > > Sorry I'm late to the party here, but would it make sense to write this as: > > (?:smp|virt)_(?:$smp_barrier_stems) Yes. Perhaps the name might be bet...

...pl b/scripts/checkpatch.pl >> [] >> > > @@ -5133,7 +5133,8 @@ sub process { >> > > }x; >> > > my $all_barriers = qr{ >> > > $barriers| >> > > - smp_(?:$smp_barrier_stems) >> > > + smp_(?:$smp_barrier_stems)| >> > > + virt_(?:$smp_barrier_stems) >> > >> > Sorry I'm late to the party here, but would it make sense to write this as: >> > >> > (?:smp|virt)_(?:$smp...

...heckpatch to make it easier to stop > incorrect memory barrier usage. > > This replaces the checkpatch patches in my series > arch: barrier cleanup + barriers for virt > and will be included in the pull request including > the series. > > changes from v3: > rename smp_barrier_stems to barrier_stems > as suggested by Julian Calaby. In fact it was Joe Perches that suggested it. Sorry about the confusion. > add (?: ... ) around a variable in regexp, > in case we change the value later so that it matters. > changes from v2: > address comments by Joe Perches:...

Hi all, Although [smp_]read_barrier_depends() became part of READ_ONCE() in commit 76ebbe78f739 ("locking/barriers: Add implicit smp_read_barrier_depends() to READ_ONCE()"), it still limps on in the Linux memory model with the sinister hope of attracting innocent new users so that it becomes impossible to remove altogether. Let's strike before it's too late: there's only

Hi all, This is version three of the patches I previously posted here: v1: https://lore.kernel.org/lkml/20191108170120.22331-1-will at kernel.org/ v2: https://lore.kernel.org/r/20200630173734.14057-1-will at kernel.org Changes since v2 include: * Actually add the barrier in READ_ONCE() for Alpha! * Implement Alpha's smp_load_acquire() using __READ_ONCE(), rather than the other

Hi everyone, This is the long-awaited version two of the patches I previously posted in November last year: https://lore.kernel.org/lkml/20191108170120.22331-1-will at kernel.org/ I ended up parking the series while the READ_ONCE() implementation was being overhauled, but with that merged during the recent merge window and LTO patches being posted again [1], it was time for a refresh. The

Hi everyone, This is the long-awaited version two of the patches I previously posted in November last year: https://lore.kernel.org/lkml/20191108170120.22331-1-will at kernel.org/ I ended up parking the series while the READ_ONCE() implementation was being overhauled, but with that merged during the recent merge window and LTO patches being posted again [1], it was time for a refresh. The