In the case of a rename replacing an existing destination inode, ramfs
Rename failed to first remove the replaced inode. This caused:
1. A leak of a reference to the inode (making it live indefinitely).
2. For directories, a leak of the replaced directory's .. link to the
parent. This would cause the parent's link count to incorrectly
increase.
(2) is much simpler to test than (1), so that's what I've done.
agentfs has a similar bug with link count only, so the Dirent layer
informs the Inode if this is a replacing rename.
Fixes#133
PiperOrigin-RevId: 239105698
Change-Id: I4450af2462d8ae3339def812287213d2cbeebde0
* open_create_test_runsc_ptrace_shared doesn't expect the write access to /
* exec_test_runsc_ptrace_shared could not find /usr/share/zoneinfo/
* clock_gettime_test_runsc_ptrace_shared didn't expect that
a thread cpu time can be zero.
* affinity_test_runsc_ptrace_shared expected minimum 3 cpus
PiperOrigin-RevId: 237509429
Change-Id: I477937e5d2cdf3f8720836bfa972abd35d8220a3
Michael Pratt
Fabricio Voznika
Andrei Vagin