mbox series

[0/2] locking/atomics: fix and improvement

Message ID 20181210175035.45096-1-mark.rutland@arm.com
Headers show
Series locking/atomics: fix and improvement | expand

Message

Mark Rutland Dec. 10, 2018, 5:50 p.m. UTC 
Hi Ingo,

I hope that these atomic scripting patches address your concerns with
the atomics scripting infrastructure. These are based on the tip
locking/core branch, leaving the headers checked-in.

The primary improvement is using a hash to detect when the headers have
been erroneously modified, meaning check-atomics.sh takes ~0.15s, which
I believe should be palatable.

It also turns out that some people are building without coreutils, so
I've picked up Anders' fix for this. Since sha1sum is part of coreutils,
the checks are skipped when this isn't present, on the assumption that
anyone actually sending patches will have a working coreutils.

Are you happy to pick these up?

Thanks,
Mark.

Anders Roxell (1):
  locking/atomics: Change 'fold' to 'grep'

Mark Rutland (1):
  locking/atomics: Check atomic headers with sha1sum

 include/asm-generic/atomic-instrumented.h |  1 +
 include/asm-generic/atomic-long.h         |  1 +
 include/linux/atomic-fallback.h           |  1 +
 scripts/atomic/atomic-tbl.sh              |  2 +-
 scripts/atomic/check-atomics.sh           | 26 ++++++++++++++++++++------
 scripts/atomic/gen-atomics.sh             | 20 ++++++++++++++++++++
 6 files changed, 44 insertions(+), 7 deletions(-)
 create mode 100755 scripts/atomic/gen-atomics.sh

-- 
2.11.0

Comments

Mark Rutland Dec. 12, 2018, 10:18 a.m. UTC | #1 
On Mon, Dec 10, 2018 at 05:50:33PM +0000, Mark Rutland wrote:
> Hi Ingo,

> 

> I hope that these atomic scripting patches address your concerns with

> the atomics scripting infrastructure. These are based on the tip

> locking/core branch, leaving the headers checked-in.

> 

> The primary improvement is using a hash to detect when the headers have

> been erroneously modified, meaning check-atomics.sh takes ~0.15s, which

> I believe should be palatable.


As a heads-up, it looks like my prior attempt [1] is in today's linux-next
(next-20181212), via Andrew's tree.

Ingo, could you please let us know what you'd prefer? Are you happy to take
this version, and should Andrew drop that patch?

Thanks,
Mark.

[1] https://lkml.kernel.org/r/20181128085455.1164-1-mark.rutland@arm.com