[mount]Fix copy file range

[zemul]

What problem are we solving?

#4405

How are we solving the problem?

Remove duplicate locks.

How is the PR tested?

local call copy_file_range.

Checks

• I have added unit tests if possible.
• I will add related wiki document changes and link to this PR after merging.

[werdnum]

Glad to see this getting attention, but FWIW you can still get a deadlock if the same goroutine acquires a read-lock twice, if some other process calls Lock() in between. See https://pkg.go.dev/sync#RWMutex:

If a goroutine holds a RWMutex for reading and another goroutine might call Lock, no goroutine should expect to be able to acquire a read lock until the initial read lock is released. In particular, this prohibits recursive read locking. This is to ensure that the lock eventually becomes available; a blocked Lock call excludes new readers from acquiring the lock.

In the terminology of the Go memory model, the n'th call to Unlock “synchronizes before” the m'th call to Lock for any n < m, just as for Mutex. For any call to RLock, there exists an n such that the n'th call to Unlock “synchronizes before” that call to RLock, and the corresponding call to RUnlock “synchronizes before” the n+1'th call to Lock.

[zemul]

Glad to see this getting attention, but FWIW you can still get a deadlock if the same goroutine acquires a read-lock twice, if some other process calls Lock() in between. See https://pkg.go.dev/sync#RWMutex:

If a goroutine holds a RWMutex for reading and another goroutine might call Lock, no goroutine should expect to be able to acquire a read lock until the initial read lock is released. In particular, this prohibits recursive read locking. This is to ensure that the lock eventually becomes available; a blocked Lock call excludes new readers from acquiring the lock.
In the terminology of the Go memory model, the n'th call to Unlock “synchronizes before” the m'th call to Lock for any n < m, just as for Mutex. For any call to RLock, there exists an n such that the n'th call to Unlock “synchronizes before” that call to RLock, and the corresponding call to RUnlock “synchronizes before” the n+1'th call to Lock.

This merge request has deleted the second lock on entryLock in the same goroutine

[werdnum]

Glad to see this getting attention, but FWIW you can still get a deadlock if the same goroutine acquires a read-lock twice, if some other process calls Lock() in between. See https://pkg.go.dev/sync#RWMutex:

If a goroutine holds a RWMutex for reading and another goroutine might call Lock, no goroutine should expect to be able to acquire a read lock until the initial read lock is released. In particular, this prohibits recursive read locking. This is to ensure that the lock eventually becomes available; a blocked Lock call excludes new readers from acquiring the lock.
In the terminology of the Go memory model, the n'th call to Unlock “synchronizes before” the m'th call to Lock for any n < m, just as for Mutex. For any call to RLock, there exists an n such that the n'th call to Unlock “synchronizes before” that call to RLock, and the corresponding call to RUnlock “synchronizes before” the n+1'th call to Lock.

This merge request has deleted the second lock on entryLock in the same goroutine

Ah, my mistake – I see that the one left is the lock on the file itself, whereas filehandle_read locks the entryLock.