[PATCH] : Grammatical fixes

  Documentation/porting: s/are/and/
  Documentation/directory-locking: s/that means// was repeated

Documentation/filesystems/directory-locking

@@ -80,14 +80,14 @@ would have a contended child and we had assumed that no object is its
 own descendent.  Moreover, there is exactly one cross-directory rename
 (see above).
 
-	Consider the object blocking the cross-directory rename.  One of
-its descendents is locked by cross-directory rename (otherwise we would again
-have an infinite set of of contended objects).  But that means that means
-that cross-directory rename is taking locks out of order.  Due to (2) the
-order hadn't changed since we had acquired filesystem lock.  But locking
-rules for cross-directory rename guarantee that we do not try to acquire
-lock on descendent before the lock on ancestor.  Contradiction.  I.e.
-deadlock is impossible.  Q.E.D.
+	Consider the object blocking the cross-directory rename.  One
+of its descendents is locked by cross-directory rename (otherwise we
+would again have an infinite set of of contended objects).  But that
+means that cross-directory rename is taking locks out of order.  Due
+to (2) the order hadn't changed since we had acquired filesystem lock.
+But locking rules for cross-directory rename guarantee that we do not
+try to acquire lock on descendent before the lock on ancestor.
+Contradiction.  I.e.  deadlock is impossible.  Q.E.D.
 
 
 	These operations are guaranteed to avoid loop creation.  Indeed,

Documentation/filesystems/porting

@@ -69,7 +69,7 @@ Locking change: ->s_vfs_rename_sem is taken only by cross-directory renames.
 Most likely there is no need to change anything, but if you relied on
 global exclusion between renames for some internal purpose - you need to
 change your internal locking.  Otherwise exclusion warranties remain the
-same (i.e. parents are victim are locked, etc.).
+same (i.e. parents and victim are locked, etc.).
 
 ---
 [informational]