[HDFS-8648] Revisit FsDirectory#resolvePath() function usage to check the call is made under proper lock

• Type: Bug
• Status: Patch Available
• Priority: Major
• Resolution: Unresolved
• Assignee: Rakesh Radhakrishnan
• Reporter: Rakesh Radhakrishnan
• Created: 23/Jun/15 05:02
• Updated: 27/Oct/16 06:27

Description

As per the discussion in HDFS-8493 the function FsDirectory#resolvePath usage needs to be reviewed. It seems there are many places it has done the resolution fsd.resolvePath(pc, src, pathComponents); by acquiring only fsn lock and not fsd lock. As per the initial analysis following are such cases, probably it needs to filter out and fix wrong usage.

1. FsDirAclOp.java
   -> getAclStatus()
   -> modifyAclEntries()
   -> removeAcl()
   -> removeDefaultAcl()
   -> setAcl()
   -> getAclStatus()
2. FsDirDeleteOp.java
   -> delete(fsn, src, recursive, logRetryCache)
3. FsDirRenameOp.java
   -> renameToInt(fsd, srcArg, dstArg, logRetryCache)
   -> renameToInt(fsd, srcArg, dstArg, logRetryCache, options)
4. FsDirStatAndListingOp.java
   -> getContentSummary(fsd, src)
   -> getFileInfo(fsd, srcArg, resolveLink)
   -> isFileClosed(fsd, src)
   -> getListingInt(fsd, srcArg, startAfter, needLocation)
5. FsDirWriteFileOp.java
   -> abandonBlock()
   -> completeFile(fsn, pc, srcArg, holder, last, fileId)
   -> getEncryptionKeyInfo(fsn, pc, src, supportedVersions)
   -> startFile()
   -> validateAddBlock()
6. FsDirXAttrOp.java
   -> getXAttrs(fsd, srcArg, xAttrs)
   -> listXAttrs(fsd, src)
   -> setXAttr(fsd, src, xAttr, flag, logRetryCache)
7. FSNamesystem.java
   -> createEncryptionZoneInt()
   -> getEZForPath()

Thanks wheat9, vinayrpet for the advice.