Details
-
Bug
-
Status: Patch Available
-
Major
-
Resolution: Unresolved
-
None
-
None
-
None
-
None
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.
- FsDirAclOp.java
-> getAclStatus()
-> modifyAclEntries()
-> removeAcl()
-> removeDefaultAcl()
-> setAcl()
-> getAclStatus() - FsDirDeleteOp.java
-> delete(fsn, src, recursive, logRetryCache) - FsDirRenameOp.java
-> renameToInt(fsd, srcArg, dstArg, logRetryCache)
-> renameToInt(fsd, srcArg, dstArg, logRetryCache, options) - FsDirStatAndListingOp.java
-> getContentSummary(fsd, src)
-> getFileInfo(fsd, srcArg, resolveLink)
-> isFileClosed(fsd, src)
-> getListingInt(fsd, srcArg, startAfter, needLocation) - FsDirWriteFileOp.java
-> abandonBlock()
-> completeFile(fsn, pc, srcArg, holder, last, fileId)
-> getEncryptionKeyInfo(fsn, pc, src, supportedVersions)
-> startFile()
-> validateAddBlock() - FsDirXAttrOp.java
-> getXAttrs(fsd, srcArg, xAttrs)
-> listXAttrs(fsd, src)
-> setXAttr(fsd, src, xAttr, flag, logRetryCache) - FSNamesystem.java
-> createEncryptionZoneInt()
-> getEZForPath()