The Specification of POSIX File Systems Gian Ntzik, Pedro da Rocha - - PowerPoint PPT Presentation

the specification of posix file systems
SMART_READER_LITE
LIVE PREVIEW

The Specification of POSIX File Systems Gian Ntzik, Pedro da Rocha - - PowerPoint PPT Presentation

The Specification of POSIX File Systems Gian Ntzik, Pedro da Rocha Pinto and Philippa Gardner Imperial College London gian.ntzik08@imperial.ac.uk pedro.da-rocha-pinto09@imperial.ac.uk p.gardner@imperial.ac.uk INVEST 2017 1/13 Logics for


slide-1
SLIDE 1

The Specification of POSIX File Systems

Gian Ntzik, Pedro da Rocha Pinto and Philippa Gardner

Imperial College London gian.ntzik08@imperial.ac.uk pedro.da-rocha-pinto09@imperial.ac.uk p.gardner@imperial.ac.uk

INVEST 2017

1/13

slide-2
SLIDE 2

2/13

Logics for Specifying Concurrent Programs

Owicki-Gries (1976) Rely-Guarantee (1983) CSL (2004) SAGL (2007) Bornat-at (2005) RGSep (2007) Deny-Guarantee (2009) Gotsman-al (2007) LRG (2009) RSL (2013) CAP (2010) HLRG (2010) RGSim (2012) HOCAP (2013) Jacobs-Piessens (2011) SCSL (2013) Liang-Feng (2013) iCAP (2014) TaDA (2014) CaReSL (2013) Iris (2015) CoLoSL (2015) FTCSL (2015) LiLi (2016) GPS (2014) Iris 2.0 (2016) Total-TaDA (2016) FCSL (2014)

Thanks, Ilya Sergey.

slide-3
SLIDE 3

3/13

POSIX File Systems

  • The POSIX standard is written in English
  • Several formal sequential specifications have been given:
  • not good for client reasoning if based on first-order logic;
  • good for client reasoning if based on separation logic.
  • The English specification of the concurrent behaviour is poor.
  • We have the first concurrent specification of POSIX file

systems.

slide-4
SLIDE 4

4/13

A POSIX operation: unlink(/usr/bin/git)

unlink(/usr/bin/git) takes a sequence of atomic actions

1 2

tmp usr

3 4 5 7

share bin local lib .X0-lock

0101111011... 8 0110011011... 9

git

slide-5
SLIDE 5

5/13

unlink(/usr/bin/git): a Sequence of Atomic Actions

FS1 FS1 FS2 FS2 FS3 FS4 Environment: mupltiple atomic updates Thread: single atomic read in path traversal Thread: single atomic update

usr bin git

unlink(/usr/bin/git)

slide-6
SLIDE 6

6/13

Concurrent Specification of unlink(path)

unlink(path) ⊑ let p = dirname(path); let a = basename(path); let r = resolve(p, ι0); if ¬iserr(r) then return link delete(r, a) ⊔ link delete notdir(r, a) else return r fi

  • link delete(r, a) atomically removes link a, even if it links a

directory

  • link delete notdir(r, a) atomically removes link a, only if

it does not link a directory

  • ⊔ : non-deterministic angelic choice
slide-7
SLIDE 7

7/13

Concurrent Specification of path resolution

letrec resolve(path, ι) if path = null then return ι else let a = head(path); let p = tail(path); let r = link lookup(ι, a); if iserr(r) then return r else return resolve(p, r) fi fi

  • link lookup(ι, a) atomically lookup the link named a in the

directory with inode ι.

slide-8
SLIDE 8

8/13

Concurrent Specification of unlink(path)

unlink(path) ⊑ let p = dirname(path); let a = basename(path); let r = resolve(p, ι0); if ¬iserr(r) then return link delete(r, a) ⊔ link delete notdir(r, a) else return r fi

slide-9
SLIDE 9

8/13

Concurrent Specification of unlink(path)

unlink(path) ⊑ let p = dirname(path); let a = basename(path); let r = resolve(p, ι0); if ¬iserr(r) then return link delete(r, a) ⊔ link delete notdir(r, a) else return r fi link delete(ι, a)

A FS. fs(FS) ∧ isdir(FS(ι)) , a ∈ FS(ι) = ⇒ fs(FS[ι → FS(ι) \ {a}]) ∗ ret = 0

⊓ return enoent(ι, a) ⊓ return enotdir(ι) enoent(ι, a) and enotdir(ι) describe error cases. ⊓ is non-deterministic demonic choice.

slide-10
SLIDE 10

9/13

Concurrent specification of link(source, target)

link(source, target) ⊑ let ps = dirname(source); let a = basename(source); let pt = dirname(target); let b = basename(target); let rs, rt = resolve(ps, ι0) resolve(pt, ι0); if ¬iserr(rs) ∧ ¬iserr(rt) then return link insert(rs, a, rt, b) ⊔ link insert notdir(rs, a, rt, b) else if iserr(rs) ∧ ¬iserr(rt) then return rs else if ¬iserr(rs) ∧ iserr(rt) then return rt else if iserr(rs) ∧ iserr(rt) then return rs ⊔ return rt fi

slide-11
SLIDE 11

10/13

Lock-file Client

◮ lock(path): atomically create a non-existing lock file at path ◮ unlock(path): remove the lock file identified by path ◮ Implemented similarly to spin locks

◮ open(path, O CREAT|O EXCL) to try to lock ◮ unlink to unlock

slide-12
SLIDE 12

11/13

Lock-file Protocol Agreement

We want the module and the environment to agree on a boundary

1 2

tmp usr

3 4 5 7

share bin local lib .X0-lock

8 0110011011... 9

git

LF

slide-13
SLIDE 13

12/13

Lock-file Specification

LF(path) ⊢ lock(path) ⊑ A v ∈ {0, 1}.

  • Lock(path, v) , Lock(path, 1) ∗ v = 0
  • LF(path) ⊢ unlock(path) ⊑
  • Lock(path, 1) , Lock(path, 0)
  • ◮ LF(path) is a context invariant denoting what the implementation and the

environment can and cannot do to the path:

◮ The path-prefix of path is not changed (everyone can only read) ◮ Only the module create the lock file at path (locks the lock) ◮ Only the module removes the lock file at path (unlocks the lock)

slide-14
SLIDE 14

13/13

Conclusions

  • Concurrent specification of the POSIX file system (fragment)
  • Combination of the refinement calculus and a modern

concurrent separation logic called TaDA

  • Client reasoning: lock files, named pipes, email server
  • Future: executable specification which we can test against

implementations

  • Future: now what about distribution....