Kevin Wolf <kw...@redhat.com> 于2020年12月10日周四 上午1:43写道： > > Am 09.12.2020 um 10:33 hat Daniel P. Berrangé geschrieben: > > On Tue, Dec 08, 2020 at 03:38:22PM +0100, Kevin Wolf wrote: > > > Am 08.12.2020 um 13:59 hat Li Feng geschrieben: > > > > This patch addresses this issue: > > > > When accessing a volume on an NFS filesystem without supporting the > > > > file lock, > > > > tools, like qemu-img, will complain "Failed to lock byte 100". > > > > > > > > In the original code, the qemu_has_ofd_lock will test the lock on the > > > > "/dev/null" pseudo-file. Actually, the file.locking is per-drive > > > > property, > > > > which depends on the underlay filesystem. > > > > > > > > In this patch, make the 'qemu_has_ofd_lock' with a filename be more > > > > generic > > > > and reasonable. > > > > > > > > Signed-off-by: Li Feng <fen...@smartx.com> > > > > > > Do you know any way how I could configure either the NFS server or the > > > NFS client such that locking would fail? For any patch related to this, > > > it would be good if I could even test the scenario. > > > > One could write a qtest that uses an LD_PRELOAD to replace the standard > > glibc fcntl() function with one that returns an error for locking commands. > > Sounds a bit ugly, but for regression testing it could make sense. > > However, part of the testing would be to verify that we our checks > actually match the kernel code, which this approach couldn't solve. > Hi, Kevin and Daniel.
How about this patch? I think it's very straightforward. Except we need a mock syscall test case. > Kevin >
