Shadow's implementation of fcntl operations manipulating record locks (F_SETLK, F_SETLKW, F_GETLK) and open file description locks (F_OFD_SETLK, F_OFD_SETLKW, F_OFD_GETLK) performs the native operation on the native open file descriptor, from Shadow's process.

This is probably ok in cases where the locks are never under contention, but will be incorrect otherwise. e.g. if two different managed processes attempt to acquire a write lock on the same region of the same file, Linux will see it as the Shadow process trying to acquire the lock twice. From the man page, I think the second attempt will succeed, which will lead to incorrect and confusing behavior:

A single process can hold only one type of lock on a file region; if a new lock is applied to an already-locked region, then the existing lock is converted to the new lock type.

Lock metadata as returned by e.g. F_GETLK also includes the pid of the process holding the lock, which will be the native PID of shadow's process instead of the emulated PID of the corresponding managed process.