the specification of posix file systems
play

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


  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

  2. Logics for Specifying Concurrent Programs Owicki-Gries (1976) Rely-Guarantee (1983) CSL (2004) Bornat-at (2005) RGSep (2007) SAGL (2007) Gotsman-al (2007) Deny-Guarantee (2009) LRG (2009) RSL (2013) CAP (2010) Jacobs-Piessens (2011) HLRG (2010) HOCAP (2013) SCSL (2013) RGSim (2012) iCAP (2014) TaDA (2014) Liang-Feng (2013) FTCSL (2015) CaReSL (2013) Iris (2015) GPS (2014) FCSL (2014) CoLoSL (2015) LiLi (2016) Iris 2.0 (2016) Total-TaDA (2016) Thanks, Ilya Sergey. 2/13

  3. 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. 3/13

  4. A POSIX operation: unlink ( / usr / bin / git ) unlink ( / usr / bin / git ) takes a sequence of atomic actions 0 tmp usr 1 2 share local .X0-lock bin 3 0101111011... 8 5 4 lib git 7 0110011011... 9 4/13

  5. unlink ( / usr / bin / git ): a Sequence of Atomic Actions unlink(/usr/bin/git) usr bin git FS 1 FS 1 FS 2 FS 2 FS 3 FS 4 Environment: mupltiple atomic updates Thread: single atomic read in path traversal Thread: single atomic update 5/13

  6. 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 6/13

  7. 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 ι . 7/13

  8. 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 8/13

  9. 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 ) � � fs( FS ) ∧ isdir( FS ( ι )) , a ∈ FS ( ι ) = ⇒ fs( FS [ ι �→ FS ( ι ) \ { a } ]) ∗ ret = 0 � A FS . ⊓ return enoent ( ι, a ) ⊓ return enotdir ( ι ) enoent ( ι, a ) and enotdir ( ι ) describe error cases. ⊓ is non-deterministic demonic choice. 8/13

  10. Concurrent specification of link ( source , target ) link ( source , target ) ⊑ let p s = dirname ( source ); let a = basename ( source ); let p t = dirname ( target ); let b = basename ( target ); let r s , r t = resolve ( p s , ι 0 ) � resolve ( p t , ι 0 ); if ¬ iserr( r s ) ∧ ¬ iserr( r t ) then return link insert ( r s , a , r t , b ) ⊔ link insert notdir ( r s , a , r t , b ) else if iserr( r s ) ∧ ¬ iserr( r t ) then return r s else if ¬ iserr( r s ) ∧ iserr( r t ) then return r t else if iserr( r s ) ∧ iserr( r t ) then return r s ⊔ return r t fi 9/13

  11. 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 10/13

  12. Lock-file Protocol Agreement We want the module and the environment to agree on a boundary 0 tmp usr LF 1 2 share .X0-lock local bin 3 8 5 4 lib git 7 0110011011... 9 11/13

  13. Lock-file Specification � � LF( path ) ⊢ lock ( path ) ⊑ v ∈ { 0 , 1 } . Lock( path , v ) , Lock( path , 1) ∗ v = 0 A � � 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) 12/13

  14. 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.... 13/13

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend