qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] file-posix: detect the lock using the real file


From: Feng Li
Subject: Re: [PATCH] file-posix: detect the lock using the real file
Date: Thu, 10 Dec 2020 23:53:09 +0800

My mistake, you are not on the receiver list of my v2.
I use the get_maintainer.sh to generate the cc list.
I will resend it to you.

Daniel P. Berrangé <berrange@redhat.com> 于2020年12月10日周四 下午11:29写道:
>
> On Thu, Dec 10, 2020 at 10:56:59PM +0800, Li Feng wrote:
> > Kevin Wolf <kwolf@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 <fengli@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.
>
> You don't seem to have attached any patch here.
>
> Regards,
> Daniel
> --
> |: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org         -o-            https://fstop138.berrange.com :|
> |: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]