Rakesh R created HDFS-8648:
------------------------------
Summary: Revisit FsDirectory#resolvePath() function usage to check
the call is made under proper lock
Key: HDFS-8648
URL: https://issues.apache.org/jira/browse/HDFS-8648
Project: Hadoop HDFS
Issue Type: Sub-task
Reporter: Rakesh R
Assignee: Rakesh R
As per the
[discussion|https://issues.apache.org/jira/browse/HDFS-8493?focusedCommentId=14595735&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14595735]
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()
Thanks [~wheat9], [~vinayrpet] for the advice.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
