Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1336192 > unrolled thread

[FAIL 0/5] Static lock analysis

Back to article view | Back to linux.kernel

Contents

  [FAIL 0/5] Static lock analysis Daniel Wagner <daniel.wagner@bmw-carit.de> - 2016-02-17 11:00 +0100
    Re: [FAIL 0/5] Static lock analysis Christopher Li <sparse@chrisli.org> - 2016-02-18 00:10 +0100

#1336192 — [FAIL 0/5] Static lock analysis

Hi,

Locking can be tricky to get right and sometimes things go wrong. This
here is/was an attempt to come up with a simple static code analysis tool
which tries to point to problematic looking.

Especially figurering out if an access to variables wihtout holding
the right lock is happenin was of interest for me.

There are alot of small and bigger problems I faced and some of
them I was able to solve a lot of them not. Surprise surprise.

Anyway I learned quite a lot by doing this and maybe this epic fail
helps someone else in some way. :)

Maybe the first 3 patches might be okay to get merged.

cheers,
daniel

Daniel Wagner (5):
  parse: Add comment to struct statement
  inspect: Show context information
  linearize: Add context symbol name when showing context instructions
  parse: Add acquire, release, requires and guarded_by attributes
  test-locks: Add lock tester

 Makefile          |    3 +-
 allocate.c        |    1 +
 allocate.h        |    1 +
 ast-inspect.c     |   27 +-
 lib.c             |    2 +
 lib.h             |    7 +
 linearize.c       |    2 +-
 parse.c           |   64 ++++
 parse.h           |    2 +-
 symbol.c          |    5 +
 symbol.h          |   17 +
 test-locks.c      | 1020 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 validation/caps.c |   80 +++++
 13 files changed, 1227 insertions(+), 4 deletions(-)
 create mode 100644 test-locks.c
 create mode 100644 validation/caps.c

-- 
2.5.0

[toc] | [next] | [standalone]

#1336867

On Wed, Feb 17, 2016 at 1:51 AM, Daniel Wagner
<daniel.wagner@bmw-carit.de> wrote:
>
> Maybe the first 3 patches might be okay to get merged.

Yes, the first 3 looks simple and obvious correct.

Chris

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web