Fix lock ordering violation introduced in cl/347704347.

We cannot hold mm.aioManager.mu while calling MUnmap, because MUnmap attempts
to aquire mm.mappingMu. This violates the lock order as documented in mm/mm.go.

PiperOrigin-RevId: 392102472
This commit is contained in:
Nicolas Lacasse
2021-08-20 17:45:33 -07:00
committed by gVisor bot
parent 154ccbae31
commit 0e49e08219
+9 -9
View File
@@ -77,15 +77,6 @@ func (mm *MemoryManager) destroyAIOContextLocked(ctx context.Context, id uint64)
return nil
}
// Only unmaps after it assured that the address is a valid aio context to
// prevent random memory from been unmapped.
//
// Note: It's possible to unmap this address and map something else into
// the same address. Then it would be unmapping memory that it doesn't own.
// This is, however, the way Linux implements AIO. Keeps the same [weird]
// semantics in case anyone relies on it.
mm.MUnmap(ctx, hostarch.Addr(id), aioRingBufferSize)
delete(mm.aioManager.contexts, id)
aioCtx.destroy()
return aioCtx
@@ -411,6 +402,15 @@ func (mm *MemoryManager) DestroyAIOContext(ctx context.Context, id uint64) *AIOC
return nil
}
// Only unmaps after it assured that the address is a valid aio context to
// prevent random memory from been unmapped.
//
// Note: It's possible to unmap this address and map something else into
// the same address. Then it would be unmapping memory that it doesn't own.
// This is, however, the way Linux implements AIO. Keeps the same [weird]
// semantics in case anyone relies on it.
mm.MUnmap(ctx, hostarch.Addr(id), aioRingBufferSize)
mm.aioManager.mu.Lock()
defer mm.aioManager.mu.Unlock()
return mm.destroyAIOContextLocked(ctx, id)