implemented fix for potential deadlock between create,link and unlink

[nadavm391]

the call to iunlockput(dp) in create and sys_unlink is done while being locked on ip. both method and sys_link, if performed on the same directory and file, attempt to lock both locks. if during iunlockput, in the time the lock is released between iunlock and iput, the lock is acquired by another method, a deadlock will occur when said method attempt to acquire ip. example- 1.process 1 calls lock(dp) in create 2.process 2 calles sys_link and reaches line 146 - ilock(dp) and attempts to acquire the lock, waiting because process 1 is locked on it. 3. process 1 calls lock(ip) and then reaches iunlockput(dp) and releases dp in iunlock. 4.process 2 acquires dp in line 146 and calls dirlink in the if right after, inside dirlink the first if is resolved to true, the same ip from process 1 returns, and process 2 attempts to acquire ip, which was already acquired by process 1, and goes to sleep. 5.process 1 continues to iput(dp) inside iunlockput and attempts to acquire dp, which is locked by process 2. both processes are waiting for each other - deadlock.

[dinarior]

This deadlock can easily be caught by modifying the usertests to repeat linkunlink tests, with CPUS > 1.

  for(i=1; i<200; i++)
  {
    printf(1,"%d \n", i);
    linkunlink();
  }

Usually catches it, but as its rare and random, more iterations are required sometimes. As @nadavm391 mentions, this is due to iunlockput(dp); reversing the order of the locks between ip and dp (file and parent) inodes, which causes a race condition, where 1 process is holding the parent inode lock, the other the file inode lock, and both are waiting for each other.

[kaashoek]

Thanks for reporting. FYI. We fixed this deadlock on the RISC-V branch (https://github.com/mit-pdos/xv6-riscv/commit/8607051b5fc79fffa319b913b19e99bc5b90e063).