On Thu, Apr 11, 2019 at 4:21 AM Patrick Donnelly <pdonnell@xxxxxxxxxx> wrote: > > On Wed, Apr 10, 2019 at 7:21 AM Jeff Layton <jlayton@xxxxxxxxxxxxxxx> wrote: > > > > > > > > > > holding caps for request may cause deadlock. For example > > > > > > > > > > - client hold Fx caps and send unlink request > > > > > - mds process request from other client, it change filelock's state to > > > > > EXCL_FOO and revoke Fx caps > > > > > - mds receives the unlink request, it can't process it because it > > > > > can't acquire wrlock on filelock > > > > > > > > > > filelock state stays in EXCL_FOO because client does not release Fx caps. > > > > > > > > > > > > > The client doing the unlink may have received a revoke for Fx on the > > > > dir at that point, but it won't have returned it yet. Shouldn't it > > > > still be considered to hold Fx on the dir until that happens? > > > > > > > > > > Client should release the Fx. But there is a problem, mds process > > > other request first after it get the release of Fx > > > > > > > As I envisioned it, the client would hold a reference to Fx while the > > unlink is in flight, so it would not return Fx until after the unlink > > has gotten an unsafe reply. > > This was my understanding as well. It seems to me that the correct > thing to do is to move forward with the understanding that the client > has a write lock on the filelock state for the directory inode (for Fx > cap) and a write lock on the linklock for the file inode (for the Lx > cap). Obtaining those locks should require cap revocation which would > cause the client to flush its buffered async unlinks. Importantly -- > and what actually needs to change (?): the MDS should skip acquiring > those locks because the client already has the appropriate caps. > > Does that work Zheng? > No. When handling unlink request, mds needs to acquire several other locks. Treating Fx/Lx caps as 'already locked' breaks the order of acquiring locks. Which will cause deadlock. > -- > Patrick Donnelly
